Re: GPL vs non-GPL device drivers

[Valdis . Kletnieks]

On Sat, 17 Feb 2007 04:44:36 -0200, Alexandre Oliva said:
> On Feb 17, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:
> > Not so. See any of the numerous cases that explain that you cannot own a
> > function using copyright. They are saying that because V J did X, he *MUST*
> > be taking their code because there is no other practical way to *do* X. This
> > is precisely what copyright *DOES* *NOT* *LET* *YOU* *DO*.
> 
> So, since there's no other way to do Yesterday, exactly as performed
> by the Beatles in the 1965 album Help!, I'm free to copy it, perform
> it, create derived versions thereof and perform them, without paying
> royalties to the current copyright holders?

No, because there's other musically valid ways to perform the song - in the
style of Wayne Newton, or the band Slipknot, or restyled as a Bach cantata.

(Incidentally - in the case of the song Yesterday, there are *two* different
performance rights to consider.  The right to play the version that's on the
album Help!, which (usually) means you (as a radio station, or background-music
vendor, or DJ at a party, etc) need to pay royalties to somebody (usually the
record label), via ASCAP or BMI (two large payment clearinghouses - usually a
radio station or DJ just pays a lump-sum per month/year and ASCAP and BMI sort
it out).  Then there's the *music* copyright, which means that Wayne Newton's
manager gets to negotiate with the group that administers the copyright on
the song *itself* for how much it will cost Wayne to record his version.  Then
the record label gets to screw Wayne out of his share of the money that ASCAP
and BMI sends the label, but that's another rant.. ;)

But trying to call a kernel function in any other way than the one intended
by the function's author *isn't* valid - it may not even compile, if the
function's parameter list is formally incorrect, or it will likely OOPS
(perhaps later, after a stray pointer does a fandango on core).  And since
there *is* only one valid way to call (for instance) kzalloc(), it becomes
a 'scenes au faire', which is what the Lexmark ruling was about.


pgpYa7CYf8oeE.pgp
Description: PGP signature

Re: GPL vs non-GPL device drivers

[Alexandre Oliva]

On Feb 17, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:

> Not so. See any of the numerous cases that explain that you cannot own a
> function using copyright. They are saying that because V J did X, he *MUST*
> be taking their code because there is no other practical way to *do* X. This
> is precisely what copyright *DOES* *NOT* *LET* *YOU* *DO*.

So, since there's no other way to do Yesterday, exactly as performed
by the Beatles in the 1965 album Help!, I'm free to copy it, perform
it, create derived versions thereof and perform them, without paying
royalties to the current copyright holders?

> The fact that they are claiming rights that are impossible with copyright
> and inconsistent with its logic. Copyright covers the one way you chose to
> do something out of the many possible ways to do it. To argue "you must have
> taken my code because you were able to *DO* X" is arguing you own every
> practical way to do X. This is what software patents do, but this is beyond
> the scope of copyright.

You're on to something, but I think you're taking it too far.

One could always create a clean-room implementation of kernel headers
and use them to build a module that presumably wouldn't be a derived
work, as long as the binary is indeed created using these clean-room
headers.  But who does that, considering how quickly kernel headers
change, and that if you build the object code using the actual kernel
headers, then the binary is likely to be a derived work of the kernel,
even if the sources still aren't?

#include 

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

[Alexandre Oliva]

On Feb 17, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:

>> Linking with kernel exported symbols in a kernel module is by many
>> people considered creating a work derived from the kernel.

> That's simply unreasonable. It is the most clear settled law that only a
> creative process can create a work for copyright purposes. Linking is an
> automated process, not a creative process. It cannot create a work at all,
> much less a derivative work.

Per this principle, it would seem that only source code and
hand-crafted object code would be governed by copyright, since
compilation is also an automated process.

FWIW, http://www.fsfla.org/?q=en/node/128#1 touches a very similar
issue, also covered in the upcoming release of the video of the FSFLA
session in the 5th GPLv3 conference.

> If you have two works, A and B, and neither is a derivative work of the
> other, linking them together cannot change the status of A or B.

IANAL, but I understand this is correct.  However, the output is
probably a derivative work of both.

Also, it's the fact that A needs to be linked with B, or vice-versa,
that's a clue that A is likely to be a derived work from B, or
vice-versa, even before they're linked together.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Block layer: separate out queue-oriented ioctls

[Jens Axboe]

On Fri, Feb 16 2007, Alan Stern wrote:
> From: James Bottomley <[EMAIL PROTECTED]>
> 
> This patch (as854) separates out the two queue-oriented ioctls from
> the rest of the block-layer ioctls.  The idea is that they should
> apply to any driver using a request_queue, even if the driver doesn't
> implement a block-device interface.  The prototypical example is the
> sg driver, to which the patch adds the new interface.
> 
> This will make it possible for cdrecord and related programs to
> retrieve reliably the max_sectors value, regardless of whether the
> user points it to an sr or an sg device.  In particular, this will
> resolve Bugzilla entry #7026.

The block bits are fine with me, the sg calling point is a bit of a sore
thumb (a char driver calling into block layer ioctls) though. So the
block layer bits are certainly ok with me, if Doug acks the sg bit I'll
merge everything up.

(patch left below)

> Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
> 
> ---
> 
> Jens:
> 
> James said that he feels you should be be the person to accept this
> patch, since it affects the block layer.  Please merge it and send it
> on up the hierarchy.
> 
> Alan Stern
> 
> 
> 
> diff --git a/block/ioctl.c b/block/ioctl.c
> index 58aab63..8444d0c 100644
> --- a/block/ioctl.c
> +++ b/block/ioctl.c
> @@ -135,6 +135,31 @@ static int put_u64(unsigned long arg, u6
>   return put_user(val, (u64 __user *)arg);
>  }
>  
> +static int blk_queue_locked_ioctl(struct request_queue *queue,
> +   unsigned cmd, unsigned long arg)
> +{
> + switch (cmd) {
> + case BLKSSZGET: /* get block device hardware sector size */
> + return put_int(arg, queue_hardsect_size(queue));
> + case BLKSECTGET:
> + return put_ushort(arg, queue->max_sectors);
> + }
> + return -ENOIOCTLCMD;
> +}
> +
> +int blk_queue_ioctl(struct request_queue *queue, unsigned cmd,
> + unsigned long arg)
> +{
> + int ret;
> +
> + lock_kernel();
> + ret = blk_queue_locked_ioctl(queue, cmd, arg);
> + unlock_kernel();
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(blk_queue_ioctl);
> +
>  static int blkdev_locked_ioctl(struct file *file, struct block_device *bdev,
>   unsigned cmd, unsigned long arg)
>  {
> @@ -154,10 +179,6 @@ static int blkdev_locked_ioctl(struct fi
>   return put_int(arg, bdev_read_only(bdev) != 0);
>   case BLKBSZGET: /* get the logical block size (cf. BLKSSZGET) */
>   return put_int(arg, block_size(bdev));
> - case BLKSSZGET: /* get block device hardware sector size */
> - return put_int(arg, bdev_hardsect_size(bdev));
> - case BLKSECTGET:
> - return put_ushort(arg, bdev_get_queue(bdev)->max_sectors);
>   case BLKRASET:
>   case BLKFRASET:
>   if(!capable(CAP_SYS_ADMIN))
> @@ -278,6 +299,8 @@ int blkdev_ioctl(struct inode *inode, st
>  
>   lock_kernel();
>   ret = blkdev_locked_ioctl(file, bdev, cmd, arg);
> + if (ret == -ENOIOCTLCMD)
> + ret = blk_queue_locked_ioctl(bdev_get_queue(bdev), cmd, arg);
>   unlock_kernel();
>   if (ret != -ENOIOCTLCMD)
>   return ret;
> diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
> index 81e3bc7..d97244b 100644
> --- a/drivers/scsi/sg.c
> +++ b/drivers/scsi/sg.c
> @@ -786,6 +786,11 @@ sg_ioctl(struct inode *inode, struct fil
>  sdp->disk->disk_name, (int) cmd_in));
>   read_only = (O_RDWR != (filp->f_flags & O_ACCMODE));
>  
> + /* block ioctls first */
> + result = blk_queue_ioctl(sdp->device->request_queue, cmd_in, arg);
> + if (result != -ENOIOCTLCMD)
> + return result;
> +
>   switch (cmd_in) {
>   case SG_IO:
>   {
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index e1c7286..550b04a 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -754,6 +754,8 @@ extern void blk_queue_prep_rq(request_qu
>  extern void blk_queue_merge_bvec(request_queue_t *, merge_bvec_fn *);
>  extern void blk_queue_dma_alignment(request_queue_t *, int);
>  extern void blk_queue_softirq_done(request_queue_t *, softirq_done_fn *);
> +extern int blk_queue_ioctl(struct request_queue *queue, unsigned cmd,
> +unsigned long arg);
>  extern struct backing_dev_info *blk_get_backing_dev_info(struct block_device 
> *bdev);
>  extern int blk_queue_ordered(request_queue_t *, unsigned, prepare_flush_fn 
> *);
>  extern void blk_queue_issue_flush_fn(request_queue_t *, issue_flush_fn *);
> 

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] 9p: add write-cache support to loose cache mode (take 4)

[Eric Van Hensbergen]

On 2/16/07, Andrew Morton <[EMAIL PROTECTED]> wrote:

On Fri, 16 Feb 2007 18:46:59 -0600
Eric Van Hensbergen <[EMAIL PROTECTED]> wrote:
> + if(!PageUptodate(page)) {
> + if (to - from != PAGE_CACHE_SIZE) {
> + void *kaddr = kmap_atomic(page, KM_USER0);
> + memset(kaddr, 0, from);
> + memset(kaddr + to, 0, PAGE_CACHE_SIZE - to);
> + flush_dcache_page(page);
> + kunmap_atomic(kaddr, KM_USER0);
> + }
> + if ((file->f_flags & O_ACCMODE) != O_WRONLY)
> + v9fs_vfs_readpage_worker(file, page);
> + }

Seems strange to memset part of the page and to then go and fill the page
in from backing store.  Perhaps some optimisation is possible here?



Just double-checking in an effort to actually get the next patch right
(hopefully) -- seems like there are two cases -- if I can read from
the file, I just call readpage and it'll zero out bits.  If the file
is open write-only, things are a little cloudy -- fs/cifs looks like
they just don't do anything.  In the write-only case, do I need to
zero the unwritten portions of the page, or does this get handled
under the covers?  Looks like NFS just avoids this by only writing the
bits that change, which I suppose has other advantages.  I'll refactor
the writepage code to follow the NFS example versus the CIFS code I
originally based my implementation on.

 -eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH(Experimental) 1/4] freezer-cpu-hotplug core

[Gautham R Shenoy]

On Fri, Feb 16, 2007 at 01:42:09PM +0530, Srivatsa Vaddagiri wrote:
> On Fri, Feb 16, 2007 at 12:46:17PM +0530, Srivatsa Vaddagiri wrote:
> > frozen. The only exception is cleaning up of per-cpu threads (which is
> > not possible with processes frozen - if we can find a way to make that
> > possible, then everything can be done in CPU_DEAD).
> 
> How abt a patch like below?
> 
> 
> --- process.c.org 2007-02-16 13:38:39.0 +0530
> +++ process.c 2007-02-16 13:38:59.0 +0530
> @@ -47,7 +47,7 @@ void refrigerator(void)
>   recalc_sigpending(); /* We sent fake signal, clean it up */
>   spin_unlock_irq(>sighand->siglock);
> 
> - while (frozen(current)) {
> + while (frozen(current) && !kthread_should_stop()) {
>   current->state = TASK_UNINTERRUPTIBLE;
>   schedule();
>   }

This looks ok, but probably we could do it in a better way.
How about an api to thaw only a specific task something like
thaw_process(struct task_struct p). 

That way, the CPU_DEAD handler which wants to kthread_stop a thread
can selectively thaw the thread before it does kthread_stop.

Rafael, does this have any negative impact on the freezer design?

> This should let us do kthread_stop() in CPU_DEAD itself (while processes
> are frozen)? That would allow us to do everything from CPU_DEAD itself
> (and not have CPU_DEAD_KILL_THREADS).
> 
> 
> -- 
> Regards,
> vatsa

thanks
gautham.
-- 
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [pp] kbuild: asm-offsets generalized

[Oleg Verych]

On Sat, Feb 17, 2007 at 03:43:49PM +1100, Rusty Russell wrote:
> On Fri, 2007-02-16 at 22:56 +0100, Oleg Verych wrote:
> > Hallo.
> 
> lguest parts look good though!

Thanks.

Well, then what about my way of doing generalization?

I.e. one-file shell script-let, rather many indistinguishable GNU make
files throughout source tree?

Sam's approach also offers using of CONGIG* options. But this has two
issues (for me, of course):

* lguest is in i386 arch, *top* Kbuild doing this for specific ARCH
(include/asm/);

* lguest wants to have private for-asm constants generated, unless CONFIG
is set, kbuild never will reach that directory.

Finally (my favorite). While i was told, that i'm doing more obfusticated
solutions, i doubt i did now: script-let makes magic more readable, and
GNU make's complications, like `$$' and various whitespace issues, do not
influence.

One thing is, that

+quiet_cmd_offsets = GEN $@
+  cmd_offsets = $(srctree)/scripts/mkCconstants $< $@
+

can be moved in Kbuild.include with CONFIG* upgrade:

sed-$(CONFIG_MIPS) = mips

  cmd_offsets = $(srctree)/scripts/mkCconstants $< $@ $(sed-y)


Kind regards!
--
-o--=O`C  info emacs : not found
 #oo'L O  info make  : not found
<___=E M  man gcc: not found
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 05/11] syslets: core code

[Ray Lee]

Evgeniy Polyakov wrote:
> On Fri, Feb 16, 2007 at 08:53:30AM -0800, Ray Lee ([EMAIL PROTECTED]) wrote:
>> On 2/16/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>>> if its design is good, then
>>> interface can be changed in a moment without any problem
>> This isn't always the case. Sometimes the interface puts requirements
>> (contract-like) upon the implementation. Case in point in the kernel,
>> dnotify versus inotify. dnotify is a steaming pile of worthlessness,
>> because it's userspace interface is so bad (meaning inefficient) as to
>> be nearly unusable.
>>
>> inotify has a different interface, one that supplies details about
>> events rather that mere notice that an event occurred, and therefore
>> has different requirements in implementation. dnotify probably was a
>> good design, but for a worthless interface.
>>
>> The interface isn't always important, but it's certainly something
>> that has to be understood before putting the finishing touches on the
>> behind-the-scenes implementation.
> 
> Absolutely.
> And if overall system design is good,

dnotify was a good system design for a stupid (or misunderstood) problem.

> there is no problem to change
> (well, for those who fail to read to the end and understand my english
> replace 'to change' with 'to create and commit') interface to the state
> where it will satisfy all (majority of) users.

You might be right, but the point I (and others) are trying to make is
that there are some cases where you *really* need to understand the
users of the interface first. You might have everything else right
(userspace wants to know when filesystem changes occur, great), but if
you don't know what form those notifications have to look like, you'll
end up doing a lot of wasted work on a worthless piece of code that no
one will ever use.

Sometimes the interface really is the most important thing. Just like a
contract between people.

(This is probably why, by the way, most people are staying silent on
your excellent kevent work. The kernel side is, in some ways, the easy
part. It's getting an interface that will handle all users [ users ==
producers and consumers of kevents ], that is the hard bit.)

Or, let me put it yet another way: How do you prove to the rest of us
that you, or Ingo, or whomever, are not building another dnotify? (Maybe
you're smart enough in this problem space that you know you're not --
that's actually the most likely possibility. But you still have to prove
it to the rest of us. Sucks, I know.)

> Situations when system is designed from interface down to system ends up
> with one thread per IO and huge limitations on how system is going to be
> used at all.

The other side is you start from the goal in mind and get Ingo's state
machines with loops and conditionals and marmalade in syslets which
appear a bit baroque and overkill for the majority of us userspace folk.

(No offense intended to Ingo, he's obviously quite a bit more conversant
on the needs of high speed interfaces than I am. However, I suspect I
have a bit more clarity on what us normal folk would actually use, and
kernel driven FSMs ain't it. Userspace often makes a lot of contextual
decisions that I would absolutely *hate* to write and debug as a state
machine that gets handed off to the kernel. I'll happily take a 10% hit
in efficiency that Moore's law will get me back in a few months, instead
of spending a bunch of time debugging difficult heisenbugs due to the
syslet FSM reading a userspace variable at a slightly different time
once in a blue moon. OTOH, I'm also not Oracle, so what do I know?)

The truth of this lies somewhere in the middle. It isn't kernel driven,
or userspace interface driven, but a tradeoff between the two.

So:

> Userspace_API_is_the_ever_possible_last_thing_to_ever_think_about.
> Period

Please listen to those of us who are saying that this might not be the
case. Maybe we're idiots, but then again maybe we're not, okay?
Sometimes the API really *DOES* change the underlying implementation.

Ray
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20 kernel hang with USB drive and vfat doing ftruncate

[Kumar Gala]

On Feb 16, 2007, at 5:10 PM, Robert Hancock wrote:


Kumar Gala wrote:
I'm seeing an issue with a stock 2.6.20 kernel running on an  
embedded PPC.  I've got a usb flash drive plugged in and the  
filesystem on the drive is vfat.  Running with 64M and no swap.
If I execute a series of large (100M+) ftruncate() on the disk the  
kernel will hang and never return.  It seems to be stuck in the  
idle loop().


On FAT filesystems this forces the entire file contents of that  
size to be written out with zeros. Are you sure the kernel just  
isn't busy writing out all that data to the disk?


I'm pretty sure, seeing as if I run the test it takes maybe 20-30  
seconds to create the file if it succeeds.  However, I've weighted 10  
minutes and still no prompt.


I'm also able to break in with a HW debugger and am always in the  
idle loop.


- k
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 00/21] Xen-paravirt: Xen guest implementation for paravirt_ops interface

[Rusty Russell]

On Fri, 2007-02-16 at 13:48 -0800, Zachary Amsden wrote:
> Christoph Lameter wrote:
> > It still seems to be implemented for Xen and not to support a variety of 
> > page table methods in paravirt ops.
> 
> Yes, but that is just because the Xen hooks happens to be near the last 
> part of the merge.  VMI required some special hooks, as do both Xen and 
> lhype (I think ... Rusty can correct me if lhype's puppy's have 
> precluded the addition of new hooks).

lguest was supposed to be a demonstration of paravirt_ops, so it
shouldn't have added any.  But note that I did change some other things,
such as the esp0 initialization for the swapper.

Puppies are still alive and well.  Although Andi not pushing into 2.6.21
(yet?) made puppies sad 8(

>   Xen page table handling is very 
> different, mostly it is trap and emulate so writable page tables can 
> work, which means they don't always issue hypercalls for PTE updates, 
> although they do have that option, should the hypervisor MMU model 
> change, or performance concerns prompt a different model (or perhaps, 
> migration?)

Yes, Xen really like their direct pagetable stuff.  I'm a
traditionalist, myself, but it did require some expansion of
paravirt_ops.

KVM might well want more, although from here it's more likely we'll move
some of the hooks up the stack a little IMHO.

Cheers,
Rusty.




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 00/21] Xen-paravirt: Xen guest implementation for paravirt_ops interface

[Rusty Russell]

On Fri, 2007-02-16 at 12:49 -0800, Christoph Lameter wrote:
> On Thu, 15 Feb 2007, Jeremy Fitzhardinge wrote:
> 
> > This patch series implements the Linux Xen guest in terms of the
> > paravirt-ops interface.  The features in implemented this patch series
> 
> I am thoroughly confused. Maybe that is because I have not been following 
> this issue closely but it seems that you are using the paravirt interface 
> as an API for Xen code in the guest? I thought the idea of paravirt was to 
> have an API that is generic? This patchset seems to be mostly realizing 
> Xen specific functionality? How does the code here interact with KVM, 
> VMWare and other hypervisors?

It doesn't.  Paravirt_ops provides the hooks.  KVM, lguest, VMI and Xen
all need to implement what they want on top of them.

Hope that clarifies,
Rusty.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20.git regression: 'PCI: add the sysfs driver name to all modules' causes hard hang on boot

[Greg KH]

On Sat, Feb 17, 2007 at 04:04:52AM +0100, Markus Rechberger wrote:
> On 2/17/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
> >On 2/17/07, Greg KH <[EMAIL PROTECTED]> wrote:
> >> On Sat, Feb 17, 2007 at 02:38:08AM +0100, Mike Galbraith wrote:
> >> > On Fri, 2007-02-16 at 14:36 -0800, Greg KH wrote:
> >> > > On Fri, Feb 16, 2007 at 10:55:10AM +0100, Mike Galbraith wrote:
> >> > > > Greetings,
> >> > > >
> >> > > > Per $subject, git.yesterday hangs hard on boot here. A git bisect
> >> > > > fingered the commit below, which I verified via git bisect reset;
> >git
> >> > > > revert -n 725522b5453dd680412f2b6463a988e4fd148757, after which box
> >> > > > boots fine.  (well, I hope I verified... i'm git-ignorant)
> >> > >
> >> > > If you change CONFIG_SYSFS_DEPRECATED to Y, does that solve the
> >problem?
> >> >
> >> > It's already set.
> >>
> >> It's not set in the config file you sent to me and the list :)
> >>
> >
> >I'm having a hard lockup to when I fire up xmms in X (maybe some other
> >apps too) I'm bisecting at the moment.
> >CONFIG_SYSFS_DEPRECIATED is set to Y here too, so I might have another
> >problem here.. let's see what bisecting will show up..
> >
> 
> seems to be a "wrong" alarm here, it was caused by a new xorg.conf and
> an intel 855gm chipset.

That's good, thanks for letting us know.

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [pp] kbuild: asm-offsets generalized

[Rusty Russell]

On Fri, 2007-02-16 at 22:56 +0100, Oleg Verych wrote:
> Hallo.

lguest parts look good though!

Rusty.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Using sched_clock for mmio-trace

[Jeff Muizelaar]

On Fri, Feb 16, 2007 at 02:47:45PM -0800, Daniel Walker wrote:
> > > Gets pretty ugly .. The clocksource interface already has a positive
> > > rating to describe the "best" clocks in the system, which is used to
> > > return the "best" clock .. Where the maintainers of the system give each
> > > clock a rating. I would imagine most people would just get the so called
> > > "best" clock which has the best rating..
> > > 
> > > I'm starting to think this long flags stringing effect could happen with
> > > negative flags also, but it's seems a lot less likely.
> > 
> > The amount of flag stringing should be the same.
> 
> I don't think so .. The common case with negative flags is no flags,
> then next would be CLOCKSOURCE_UNSTABLE. At most I would guess two
> flags .. The other direction your likely to have people using all flags
> most of the time. That's why I showed a function call with all the flags
> listed.

I think you still misunderstand me. The common case is still no flags.

clocksource_get_clock_must_have(0) would return clocks that are stable
and unstable. clocksource_get_clock_must_have(CLOCKSOURCE_STABLE) would
only return clocks that are stable, just like
clocksource_get_clock_masked(CLOCKSOURCE_UNSTABLE) only returns clocks
that are stable.

> > > > instead of
> > > > 
> > > > clocksource_get_clock_masked(CLOCKSOURCE_UNSTABLE)
> > > > clocksource_get_clock_masked(CLOCKSOURCE_PM_AFFECTED)
> > > > 
> > > > Especially awkward is the CLOCKSOURCE_64BIT flag, as there isn't really
> > > > anyway to specify that I want a 64bit timer, only a way to specify that
> > > > I don't.
> > > 
> > > I might add a way to get specific flags, but I still think the flags
> > > should be mostly negative features.
> > 
> > Yeah, the problem is that all of the features are negative except for
> > CLOCKSOURCE_64BIT, so you can't mask for it.
> 
> It's meant as a negative feature. So you can mask it if you can't handle
> the math .. The only 64bit clock I know off is the tsc, and it's got the
> highest rating of all clocks.

Ah ok, I see that now. Maybe CLOCKSOURCE_OVER_32BITS would be a better
name? It might convey the negativity better...

-Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

[Gene Heskett]

On Friday 16 February 2007, Michael K. Edwards wrote:
>On 2/15/07, Gene Heskett <[EMAIL PROTECTED]> wrote:
>[ignorant silliness]
>
>> There is no one to my knowledge here, who would not cheer loudly once
>> a verdict was rendered because that courts decision would give the
>> FOSS community a quotable case law as to exactly what is, and is not
>> legal for you to do with GPL'd code.  We would after 16+ years of the
>> GPL, finally have a firm, well defined line drawn in the sand, a
>> precedence in US case law that at present, only exists in Germany.
>
>Oferchrissake.  We do have a US precedent, insofar as a decision in a
>court of fact on issues of fact can ever be a precedent in a common
>law system (hint: zero, unless the later judge feels like quoting some
>compelling prose).  That would be Progress Software v. MySQL (also
>known as MySQL v. NuSphere in some commentators' writings).  The FSF
>interpretation of the GPL lost.

Pacer citations please.

>Completely.  Which is true also of 
>the Munich and Frankfurt decisions.
>
>The plaintiffs, as authors of GPL works, got a full hearing in each
>case -- via routine reasoning about the GPL as an offer of contract,
>whose conditions either had (Progress Software) or had not
>(Fortinet/Sitecom and D-Link) been performed to the extent necessary
>for the defendant to claim license under the GPL.  MySQL did obtain a
>preliminary injunction, but on unrelated trademark license grounds;
>the GPL claim got them nowhere, for at least four distinct reasons
>stated in the opinion.  Harald's recovery was limited to statutory
>costs and, in the Munich case, an injunction to _either_ offer the
>source code of netfilter/iptables itself _or_ stop shipping product.
>Both German courts refused to find contract "in personam" (necessary
>to a breach of contract claim, in turn necessary to a demand for
>specific performance).
>
>"GPL is a creature of copyright law" lost in court, every time.
>"Section 4 is a limitation of scope, not a conditional performance"
>lost.  "You can lose your license irrevocably" lost.  "We can compel
>disclosure of source code with no alternative" lost.  "We can
>circumvent contract law standards of breach and remedy" lost.
>Everything RMS and Eben Moglen have ever written about the legal
>meaning of the GPL is wrong, and where "derivative works" are
>concerned, embarrassingly hypocritical as well.  Take the Big Lie
>elsewhere, please!
>
>- Michael



-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2007 by Maurice Eugene Heskett, all rights reserved.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] Re: [patch 14/21] Xen-paravirt: Add XEN config options and disable unsupported config options.

[Rusty Russell]

On Fri, 2007-02-16 at 02:19 -0800, Zachary Amsden wrote:
> Doesn't stop_machine_run already take care of getting you out of all 
> kernel threads?  So you can only be sleeping, not preempted, in which 
> case, this might not be an issue?

No, stop_machine only protects against preempt-disabled regions.

I thought about making that particularly hammer bigger, but noone had
needed it yet.  It would simply require a runtime way of disabling
further preemption and flushing preempted threads (AFAICT there can be
no deadlock issues with this).

Rusty.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

On 2/15/07, Gene Heskett <[EMAIL PROTECTED]> wrote:
[ignorant silliness]

There is no one to my knowledge here, who would not cheer loudly once a
verdict was rendered because that courts decision would give the FOSS
community a quotable case law as to exactly what is, and is not legal for
you to do with GPL'd code.  We would after 16+ years of the GPL, finally
have a firm, well defined line drawn in the sand, a precedence in US case
law that at present, only exists in Germany.


Oferchrissake.  We do have a US precedent, insofar as a decision in a
court of fact on issues of fact can ever be a precedent in a common
law system (hint: zero, unless the later judge feels like quoting some
compelling prose).  That would be Progress Software v. MySQL (also
known as MySQL v. NuSphere in some commentators' writings).  The FSF
interpretation of the GPL lost.  Completely.  Which is true also of
the Munich and Frankfurt decisions.

The plaintiffs, as authors of GPL works, got a full hearing in each
case -- via routine reasoning about the GPL as an offer of contract,
whose conditions either had (Progress Software) or had not
(Fortinet/Sitecom and D-Link) been performed to the extent necessary
for the defendant to claim license under the GPL.  MySQL did obtain a
preliminary injunction, but on unrelated trademark license grounds;
the GPL claim got them nowhere, for at least four distinct reasons
stated in the opinion.  Harald's recovery was limited to statutory
costs and, in the Munich case, an injunction to _either_ offer the
source code of netfilter/iptables itself _or_ stop shipping product.
Both German courts refused to find contract "in personam" (necessary
to a breach of contract claim, in turn necessary to a demand for
specific performance).

"GPL is a creature of copyright law" lost in court, every time.
"Section 4 is a limitation of scope, not a conditional performance"
lost.  "You can lose your license irrevocably" lost.  "We can compel
disclosure of source code with no alternative" lost.  "We can
circumvent contract law standards of breach and remedy" lost.
Everything RMS and Eben Moglen have ever written about the legal
meaning of the GPL is wrong, and where "derivative works" are
concerned, embarrassingly hypocritical as well.  Take the Big Lie
elsewhere, please!

- Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] killing the NR_IRQS arrays.

[Benjamin Herrenschmidt]

On Sat, 2007-02-17 at 02:37 +0100, Arnd Bergmann wrote:
> On Friday 16 February 2007 23:37, Benjamin Herrenschmidt wrote:
> > You might want to have a look at the powerpc API with it's remaping
> > capabilities. It's very nice for handling multiple domain spaces. It
> > might be of some use for you.
> 
> I don't consider the powerpc virtual IRQs a solution for the problem.
> While I believe you did the right thing for powerpc with generalizing
> this over all its platforms, it really isn't more than a workaround
> for the problem that we can't deal well with the static irq_desc
> array.

It's not a solution per-se, though it contains elements of solution like
the reverse mappin, which I use to map HW numbers to virtual irqs but
can trivially adapt to map HW numbers to irq_desc pointers.

Among other things, I want to make sure that we don't end up with just
putting an irq number in a field of the irq_desc and have half of the
drivers peek at it and assume we can convert between irq_desc* and
number in arbitrary ways.

The HW irq number should be as much opaque as possible from the world
outside of the PIC code and/or arch code that assign them. That's an
area where the powerpc and/or sparc code might be of use.


> When that problem is now getting worse on other architectures, we
> should try to get it right on all of them, rather than spreading
> the workaround further.

Yes, but I'd like aspects of my remapping work to be included in
whatever we come up with, which is to have the new irq_desc either hide
the underlying HW number, or at least associate it make it very clear
that it's an opaque token and not guaranteed to be unique accross
multiple PICs in the system.

In addition, if we remove the numbers, archs will need basically the
exact same services provided by the powerpc irq core for reverse mapping
(going from a HW irq number on a given PIC back to an irq_desc *).

Either using a linear array for simple PICs or a radix tree for
platforms with very big interrupt numbers (BTW. I think we have lockless
radix trees nowadays, I can remove the spinlocks to protect it in the
powerpc remapper).

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: O2micro smartcard reader driver.

[Markus Rechberger]

Hi Eric,

I committed your code to linuxtv.org to review and modify it there.
http://linuxtv.org/hg/~mrechberger/chipcardreader

one thing I noticed is the error handling in ozscr_probe.

I'll continue the rest during the next few days, I'd like to see it as
soon as possible in the upstream kernel before some kernel api changes
again which affects your current driver.

Markus

On 2/17/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:

Hi,

so finally I'm also looking at that driver,
http://pieleric.free.fr/o2scr/
the driver compiles fine, though it doesn't seem to work (unless I'm
doing something wrong here)

dmesg shows up following entries:

pccard: card ejected from slot 1
PCMCIA: socket c160c364: *** DANGER *** unable to remove socket power
pccard: PCMCIA card inserted into slot 1
pcmcia: registering new device pcmcia1.0
pccard: card ejected from slot 1
PCMCIA: socket c160c364: *** DANGER *** unable to remove socket power
pccard: PCMCIA card inserted into slot 1
pcmcia: registering new device pcmcia1.0
pccard: card ejected from slot 1
PCMCIA: socket c160c364: *** DANGER *** unable to remove socket power
pccard: PCMCIA card inserted into slot 1
pcmcia: registering new device pcmcia1.0
OZSCRLX O2Micro SmartCardBus Reader (for kernel >= 2.6.17)

The module for any reason has a usecount value of 1
ozscrlx21548  1

devicenode /dev/ozscrlx isn't opened anywhere either.

I'll do some further investigations uppon it, I'd also like to see it
directly in the kernel. It would be handy to use for encrypted
filesystems.

Markus


On 12/12/06, Eric Piel <[EMAIL PROTECTED]> wrote:
> 28.11.2006 12:49, Oliver Neukum wrote/a écrit:
> >> Latest version I've published is there:
> >> http://pieleric.free.fr/o2scr/
> >
> > case OZSCR_OPEN: /* Request ICC */
> > dprintk("OZSCR_OPEN\n");
> > ATRLength = ATR_SIZE;
> > pRdrExt->IOBase = (PSCR_REGISTERS *) dev->io_base; //XXX
> necessary?
> > pRdrExt->membase = dev->am_base; //XXX necessary?
> >
> > pRdrExt->m_SCard.AvailableProtocol = 0;
> > pRdrExt->m_SCard.RqstProtocol = 0;
> > dprintk("membase:%p\n", pRdrExt->membase);
> > dprintk("ioport:0x%03x\n", (unsigned)pRdrExt->IOBase);
> >
> > ret = CmdResetReader( pRdrExt, FALSE, ATRBuffer, 
);
> > apdu.LengthOut = ATRLength;
> >
> > #ifdef PCMCIA_DEBUG
> > printk(KERN_DEBUG "Open finished, ATR buffer = ");
> > for( ATRLength = 0; ATRLength < apdu.LengthOut; ATRLength++
)
> > printk(" [%02X] ", ATRBuffer[ATRLength] );
> > printk("\n");
> > #endif
> >
> > memcpy( apdu.DataOut, ATRBuffer, ATRLength );
> > ret = copy_to_user((struct ozscr_apdu *)arg, ,
> sizeof(struct ozscr_apdu));
> > break;
> >
> > 1. This needs locking against concurrent ioctls
> > 2. The interpretation of copy_to_user()'s return code is incorrect
> >
>
> Hi Oliver,
>
> Thanks a lot for reading my code, I didn't even hope that someone would!
> I've corrected the copy_to_user (and copy_from_user) code. However I
> don't know how to do locking for the concurrent ioctls. Indeed, I don't
> think there is anything preventing two programs to call the driver at
> the same time. Unfortunately, I've got no idea how to do the locking and
> surprisingly couldn't find any ioctl code in the kernel doing locking.
> Maybe I've just not looked at the right place, could you give a me some
> hint how to do locking for ioctl's ?
>
> See you,
> Eric
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


--
Markus Rechberger




--
Markus Rechberger
--- ozscrlx.c.1	2006-12-12 22:28:24.0 +0100
+++ ozscrlx.c	2007-02-17 01:00:46.0 +0100
@@ -596,14 +596,14 @@
 	dev = kzalloc(sizeof(struct ozscr_dev_t), GFP_KERNEL);
 	if (dev == NULL) {
 		dprintk("allocate ozscr_dev_t fail\n");
-		goto ErrHandle;
+		goto ErrHandle1;
 	}
 
 	/* Allocate space for private device-specific data */
 	dev->o2scr_reader = kzalloc(sizeof(READER_EXTENSION *), GFP_KERNEL);
 	if (dev->o2scr_reader == NULL) {
 		dprintk("allocate READER_EXTENSION fail\n");
-		goto ErrHandle;
+		goto ErrHandle2;
 	}
 
 	p_dev->priv = dev;
@@ -628,7 +628,7 @@
 
 	ret = ozscr_config(p_dev);
 	if (ret)
-		goto ErrHandle;
+		goto ErrHandle3;
 
 	// it's just so redundant... we could merge those fields together
 	dev->o2scr_reader->IOBase = (PSCR_REGISTERS *) dev->io_base;
@@ -644,11 +644,11 @@
 	dprintk("function complete\n");
 	return 0;
 
-  ErrHandle:
-	/* Free the allocated memory space */
-	if (dev)
-		kfree(dev->o2scr_reader);
+  ErrHandle3:
+	kfree(dev->o2scr_reader);
+  ErrHandle2:
 	kfree(dev);
+  ErrHandle1:
 	return ret;
 }
 

[GIT PATCH] ACPI patches for 2.6.21 - part II (resend)

[Len Brown]

Hi Linus,

please pull from: 

git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release

This...

Fixes some battery, thermal, and fan related bugs.
Adds the sony-laptop driver, which controls brightness on akpm's vaio...
Removes the experimental hotkey driver, per schedule.
Adds the ACPI support needed by the upcoming rtc driver
Fixes a suspend regression caused by part I
Fixes an IA64 processor driver regression caused by part I

... and updates the files shown below.

thanks!

-Len

ps. individual patches are available on linux-acpi@vger.kernel.org
and a consolidated plain patch is available here:
ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.20/acpi-release-20070126-2.6.20.diff.gz

 Documentation/acpi-hotkey.txt  |   38 
 Documentation/feature-removal-schedule.txt |   23 
 Documentation/sony-laptop.txt  |  106 +
 MAINTAINERS|9 
 arch/i386/kernel/acpi/boot.c   |5 
 arch/ia64/kernel/acpi.c|4 
 arch/x86_64/kernel/early-quirks.c  |4 
 drivers/acpi/Kconfig   |   10 
 drivers/acpi/Makefile  |1 
 drivers/acpi/ac.c  |9 
 drivers/acpi/acpi_memhotplug.c |9 
 drivers/acpi/asus_acpi.c   |   20 
 drivers/acpi/battery.c |   24 
 drivers/acpi/bay.c |  107 -
 drivers/acpi/bus.c |   30 
 drivers/acpi/button.c  |7 
 drivers/acpi/cm_sbs.c  |2 
 drivers/acpi/container.c   |9 
 drivers/acpi/debug.c   |2 
 drivers/acpi/dispatcher/dsmethod.c |   12 
 drivers/acpi/dock.c|8 
 drivers/acpi/ec.c  |9 
 drivers/acpi/event.c   |2 
 drivers/acpi/events/evgpe.c|   11 
 drivers/acpi/events/evmisc.c   |   11 
 drivers/acpi/executer/exdump.c |2 
 drivers/acpi/executer/exmutex.c|   36 
 drivers/acpi/fan.c |9 
 drivers/acpi/glue.c|   62 +
 drivers/acpi/hardware/hwsleep.c|   13 
 drivers/acpi/hotkey.c  | 1042 -
 drivers/acpi/i2c_ec.c  |5 
 drivers/acpi/ibm_acpi.c|   18 
 drivers/acpi/numa.c|   18 
 drivers/acpi/osl.c |   35 
 drivers/acpi/pci_bind.c|2 
 drivers/acpi/pci_irq.c |2 
 drivers/acpi/pci_link.c|5 
 drivers/acpi/pci_root.c|5 
 drivers/acpi/power.c   |  156 ++
 drivers/acpi/processor_core.c  |   13 
 drivers/acpi/processor_idle.c  |   11 
 drivers/acpi/processor_perflib.c   |3 
 drivers/acpi/processor_thermal.c   |3 
 drivers/acpi/processor_throttling.c|3 
 drivers/acpi/sbs.c |   25 
 drivers/acpi/scan.c|3 
 drivers/acpi/sleep/main.c  |3 
 drivers/acpi/system.c  |3 
 drivers/acpi/tables.c  |   41 
 drivers/acpi/tables/tbxface.c  |9 
 drivers/acpi/thermal.c |   37 
 drivers/acpi/toshiba_acpi.c|6 
 drivers/acpi/utilities/utdelete.c  |1 
 drivers/acpi/utils.c   |2 
 drivers/acpi/video.c   |9 
 drivers/misc/Kconfig   |   15 
 drivers/misc/Makefile  |1 
 drivers/misc/asus-laptop.c |5 
 drivers/misc/sony-laptop.c |  562 +
 drivers/pnp/pnpacpi/Kconfig|   16 
 drivers/usb/misc/appledisplay.c|4 
 include/acpi/acinterp.h|3 
 include/acpi/acobject.h|2 
 include/acpi/acpi_drivers.h|   40 
 include/acpi/acpiosxf.h|6 
 include/asm-i386/acpi.h|1 
 include/linux/acpi.h   |8 
 68 files changed, 1170 insertions(+), 1547 deletions(-)

through these commits:

Ahmed S. Darwish (1):
  ACPI: toshiba_acpi: Use ARRAY_SIZE macro when appropriate

Al Viro (1):
  ACPI: bay: fix wrong order of kzalloc arguments

Alessandro Guido (2):
  sony_acpi: Add backlight support to the sony_acpi
  sony_acpi: Add backlight support to the sony_acpi v2

Alexey Starikovskiy (7):
  ACPI: Disable GPEs in preparation for sleep.
  ACPI: invoke acpi_sleep_init() earlier
  ACPI: IA64: fix calculation of apic_id
  ACPI: Disable wake GPEs only once.
  ACPICA: fix AML mutex re-entrancy
  Execute AML Notify() requests on stack.
  ACPI: ec: 

[PATCH] Fix build errors if bitop functions are do {} while macros.

[Ralf Baechle]

If one of clear_bit, change_bit or set_bit is defined as a do { } while (0)
function usage of these functions in parenthesis like

  (foo_bit(23, ))

while be expaned to something like

  (do { ... } while (0)}).

resulting in a build error.  This patch removes the useless parenthesis.

Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>

diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
index 3f1b382..5231ed7 100644
--- a/drivers/block/floppy.c
+++ b/drivers/block/floppy.c
@@ -297,17 +297,17 @@ static int initialising = 1;
 #define DRS (_state[current_drive])
 #define DRWE (_errors[current_drive])
 #define FDCS (_state[fdc])
-#define CLEARF(x) (clear_bit(x##_BIT, >flags))
-#define SETF(x) (set_bit(x##_BIT, >flags))
-#define TESTF(x) (test_bit(x##_BIT, >flags))
+#define CLEARF(x) clear_bit(x##_BIT, >flags)
+#define SETF(x) set_bit(x##_BIT, >flags)
+#define TESTF(x) test_bit(x##_BIT, >flags)
 
 #define UDP (_params[drive])
 #define UDRS (_state[drive])
 #define UDRWE (_errors[drive])
 #define UFDCS (_state[FDC(drive)])
-#define UCLEARF(x) (clear_bit(x##_BIT, >flags))
-#define USETF(x) (set_bit(x##_BIT, >flags))
-#define UTESTF(x) (test_bit(x##_BIT, >flags))
+#define UCLEARF(x) clear_bit(x##_BIT, >flags)
+#define USETF(x) set_bit(x##_BIT, >flags)
+#define UTESTF(x) test_bit(x##_BIT, >flags)
 
 #define DPRINT(format, args...) printk(DEVICE_NAME "%d: " format, 
current_drive , ## args)
 
diff --git a/include/linux/sunrpc/sched.h b/include/linux/sunrpc/sched.h
index de9fc57..3069ecc 100644
--- a/include/linux/sunrpc/sched.h
+++ b/include/linux/sunrpc/sched.h
@@ -150,10 +150,10 @@ struct rpc_call_ops {
 #define RPC_TASK_HAS_TIMER 3
 #define RPC_TASK_ACTIVE4
 
-#define RPC_IS_RUNNING(t)  (test_bit(RPC_TASK_RUNNING, &(t)->tk_runstate))
-#define rpc_set_running(t) (set_bit(RPC_TASK_RUNNING, &(t)->tk_runstate))
+#define RPC_IS_RUNNING(t)  test_bit(RPC_TASK_RUNNING, &(t)->tk_runstate)
+#define rpc_set_running(t) set_bit(RPC_TASK_RUNNING, &(t)->tk_runstate)
 #define rpc_test_and_set_running(t) \
-   (test_and_set_bit(RPC_TASK_RUNNING, 
&(t)->tk_runstate))
+   test_and_set_bit(RPC_TASK_RUNNING, 
&(t)->tk_runstate)
 #define rpc_clear_running(t)   \
do { \
smp_mb__before_clear_bit(); \
@@ -161,8 +161,8 @@ struct rpc_call_ops {
smp_mb__after_clear_bit(); \
} while (0)
 
-#define RPC_IS_QUEUED(t)   (test_bit(RPC_TASK_QUEUED, &(t)->tk_runstate))
-#define rpc_set_queued(t)  (set_bit(RPC_TASK_QUEUED, &(t)->tk_runstate))
+#define RPC_IS_QUEUED(t)   test_bit(RPC_TASK_QUEUED, &(t)->tk_runstate)
+#define rpc_set_queued(t)  set_bit(RPC_TASK_QUEUED, &(t)->tk_runstate)
 #define rpc_clear_queued(t)\
do { \
smp_mb__before_clear_bit(); \
@@ -179,7 +179,7 @@ struct rpc_call_ops {
smp_mb__after_clear_bit(); \
} while (0)
 
-#define RPC_IS_ACTIVATED(t)(test_bit(RPC_TASK_ACTIVE, &(t)->tk_runstate))
+#define RPC_IS_ACTIVATED(t)test_bit(RPC_TASK_ACTIVE, &(t)->tk_runstate)
 
 /*
  * Task priorities.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ck] Re: 2.6.20-ck1

[Con Kolivas]

On Saturday 17 February 2007 13:15, michael chang wrote:
> On 2/16/07, Con Kolivas <[EMAIL PROTECTED]> wrote:
> > I'm thru with bashing my head against the wall.
>
> I do hope this post isn't in any way redundant, but from what I can
> see, this has never been suggested... (someone please do enlighten me
> if I'm wrong.)
>
> Has anyone tried booting a kernel with the various patches in question
> with a mem=###M boot flag (maybe mem=96M or some other "insanely low
> number" ?) to make the kernel think it has less memory than is
> physically available (and then compare to vanilla with the same
> flags)? It might more clearly demonstrate the effects of Con's patches
> when the kernel thinks (or knows) it has relatively little memory
> (since many critics, from what I can tell, have quite a bit of memory
> on their systems for their workloads).
>
> Just my two cents.

Oh that's not a bad idea of course. I've been testing it like that for ages, 
and there are many -ck users who have testified to swap prefetch helping in 
low memory situations for real as well. Now how do you turn those testimonies 
into convincing arguments? Maintainers are far too busy off testing code for 
16+ cpus, petabytes of disk storage and so on to try it for themselves.  Plus 
they worry incessantly that my patches may harm those precious machines' 
performance... 

-- 
-ck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

exporting LANG=C (Re: [PATCH] override build timestamp)

[Oleg Verych]

> From: Olaf Hering
> Newsgroups: gmane.linux.kernel
> Subject: [PATCH] override build timestamp
> Date: Fri, 16 Feb 2007 22:52:13 +0100

Hallo, Olaf.

> Pass a timestamp to kbuild via an enviroment variable.
>
> TZ=UTC BUILD_TIMESTAMP=2007-01-01 make -kj O=../O vmlinux
>
> This can be used when the kernel source is in a SCM and uname -v
> is supposed to give the commit date and not the package build time.

While adding this functionality must be decided by kbuild developers,
could you make separate patch with exporting 'LANG=C' on the very
beginning and delete all other occurrences of it? It's a C header file
generation and afaik, it must be ASCII.

Thanks.

> Signed-off-by: Olaf Hering <[EMAIL PROTECTED]>
>
> ---
>  scripts/mkcompile_h |7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> Index: linux-2.6/scripts/mkcompile_h
>===
> --- linux-2.6.orig/scripts/mkcompile_h
> +++ linux-2.6/scripts/mkcompile_h
> @@ -30,7 +30,12 @@ UTS_VERSION="#$VERSION"
>  CONFIG_FLAGS=""
>  if [ -n "$SMP" ] ; then CONFIG_FLAGS="SMP"; fi
>  if [ -n "$PREEMPT" ] ; then CONFIG_FLAGS="$CONFIG_FLAGS PREEMPT"; fi
> -UTS_VERSION="$UTS_VERSION $CONFIG_FLAGS `LC_ALL=C LANG=C date`"
> +if [ -n "$BUILD_TIMESTAMP" ]; then
> +  TIMESTAMP="`LC_ALL=C LANG=C date -d "$BUILD_TIMESTAMP"`"
> +else
> +  TIMESTAMP="`LC_ALL=C LANG=C date`"
> +fi
> +UTS_VERSION="$UTS_VERSION $CONFIG_FLAGS $TIMESTAMP"
>  
>  # Truncate to maximum length
>  
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] - acpi_boot_init() making bad check on return code

[Len Brown]

Applied.

thanks,
-Len
On Friday 16 February 2007 16:07, John Keller wrote:
> acpi_boot_init() is making a bad check on the return
> status from acpi_table_parse(). acpi_table_parse() now
> returns zero on success, one on failure.
> 
> Signed-off-by: Aaron Young <[EMAIL PROTECTED]>
> ---
> 
> Index: release/arch/ia64/kernel/acpi.c
> ===
> --- release.orig/arch/ia64/kernel/acpi.c  2007-02-16 08:58:10.0 
> -0600
> +++ release/arch/ia64/kernel/acpi.c   2007-02-16 09:03:16.893360100 -0600
> @@ -651,7 +651,7 @@ int __init acpi_boot_init(void)
>* information -- the successor to MPS tables.
>*/
>  
> - if (acpi_table_parse(ACPI_SIG_MADT, acpi_parse_madt) < 1) {
> + if (acpi_table_parse(ACPI_SIG_MADT, acpi_parse_madt)) {
>   printk(KERN_ERR PREFIX "Can't find MADT\n");
>   goto skip_madt;
>   }
> @@ -702,7 +702,7 @@ int __init acpi_boot_init(void)
>* gets interrupts such as power and sleep buttons.  If it's not
>* on a Legacy interrupt, it needs to be setup.
>*/
> - if (acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt) < 1)
> + if (acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt))
>   printk(KERN_ERR PREFIX "Can't find FADT\n");
>  
>  #ifdef CONFIG_SMP
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20.git regression: 'PCI: add the sysfs driver name to all modules' causes hard hang on boot

[Markus Rechberger]

On 2/17/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:

On 2/17/07, Greg KH <[EMAIL PROTECTED]> wrote:
> On Sat, Feb 17, 2007 at 02:38:08AM +0100, Mike Galbraith wrote:
> > On Fri, 2007-02-16 at 14:36 -0800, Greg KH wrote:
> > > On Fri, Feb 16, 2007 at 10:55:10AM +0100, Mike Galbraith wrote:
> > > > Greetings,
> > > >
> > > > Per $subject, git.yesterday hangs hard on boot here. A git bisect
> > > > fingered the commit below, which I verified via git bisect reset;
git
> > > > revert -n 725522b5453dd680412f2b6463a988e4fd148757, after which box
> > > > boots fine.  (well, I hope I verified... i'm git-ignorant)
> > >
> > > If you change CONFIG_SYSFS_DEPRECATED to Y, does that solve the
problem?
> >
> > It's already set.
>
> It's not set in the config file you sent to me and the list :)
>

I'm having a hard lockup to when I fire up xmms in X (maybe some other
apps too) I'm bisecting at the moment.
CONFIG_SYSFS_DEPRECIATED is set to Y here too, so I might have another
problem here.. let's see what bisecting will show up..



seems to be a "wrong" alarm here, it was caused by a new xorg.conf and
an intel 855gm chipset.

Markus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: GPL vs non-GPL device drivers

[David Schwartz]

> Linking with kernel exported symbols in a kernel module is by many
> people considered creating a work derived from the kernel.

That's simply unreasonable. It is the most clear settled law that only a
creative process can create a work for copyright purposes. Linking is an
automated process, not a creative process. It cannot create a work at all,
much less a derivative work.

If you have two works, A and B, and neither is a derivative work of the
other, linking them together cannot change the status of A or B. Whether a
work is a derivative work of another is dependent on what the work *is*, not
anything you do with it. The result of the linking of A and B is an
aggregate of A and B and not a single work at all.

I think you severely misstate their position (or I'm overestimating their
understanding). The position of many people is that if you create a work
that is capable of being linked with kernel exported modules, that work
would have to contain so much internal knowledge of (and actual code from)
the kernel that it would have to be a derivative work of it. This would be
true whether or not anybody actually did link it.

Linking cannot change the status of the works linked. The process of linking
is not created and cannot produce a new work.

DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2.6.21-rc1] ibmebus: Use of_device_uevent()

[Hoang-Nam Nguyen]

This patch replaces ibmebus_uevent() by Sylvain's generic function.


Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---


 ibmebus.c |   37 +++--
 1 file changed, 3 insertions(+), 34 deletions(-)


diff -urp a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
--- a/arch/powerpc/kernel/ibmebus.c 2007-02-17 03:25:53.403375784 +0100
+++ b/arch/powerpc/kernel/ibmebus.c 2007-02-17 03:27:28.230336112 +0100
@@ -372,41 +372,10 @@ static int ibmebus_bus_match(struct devi
return 0;
 }
 
-static int ibmebus_uevent(struct device *dev, char **envp, int num_envp,
-   char *buffer, int buffer_size)
-{
-   const struct ibmebus_dev *ebus_dev = to_ibmebus_dev(dev);
-   char *name, *cp, *loc_code;
-   int length;
-
-   if (!num_envp)
-   return -ENOMEM;
-
-   if (!ebus_dev->ofdev.node)
-   return -ENODEV;
-
-   name = (char *)get_property(ebus_dev->ofdev.node, "name", NULL);
-   cp = (char *)get_property(ebus_dev->ofdev.node, "compatible", NULL);
-   loc_code = (char *)get_property(ebus_dev->ofdev.node,
-   "ibm,loc-code", NULL);
-   if (!(name && cp && loc_code))
-   return -ENODEV;
-
-   envp[0] = buffer;
-   length = scnprintf(buffer, buffer_size,
-  "MODALIAS=ibmebus:T%s:S%s:L%s",
-  name, cp, loc_code);
-   if (buffer_size - length <= 0)
-   return -ENOMEM;
-   envp[1] = NULL;
-
-   return 0;
-}
-
 struct bus_type ibmebus_bus_type = {
-   .name = "ibmebus",
-   .uevent = ibmebus_uevent,
-   .match = ibmebus_bus_match,
+   .name   = "ibmebus",
+   .uevent = of_device_uevent,
+   .match  = ibmebus_bus_match,
 };
 EXPORT_SYMBOL(ibmebus_bus_type);
 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 2/2] sched: dynticks idle load balancing - v2

[Siddha, Suresh B]

Changes since v1:

  - Move the idle load balancer selection from schedule()
to the first busy scheduler_tick() after restarting the tick.
This will avoid the unnecessay ownership changes when 
softirq's(which are run in softirqd context in certain -rt
configurations) like timer, sched are invoked for every idle tick
that happens.

  - Misc cleanups.

---
Fix the process idle load balancing in the presence of dynticks.
cpus for which ticks are stopped will sleep till the next event wakes it up.
Potentially these sleeps can be for large durations and during which today,
there is no periodic idle load balancing being done.

This patch nominates an owner among the idle cpus, which does the idle load
balancing on behalf of the other idle cpus. And once all the cpus are
completely idle, then we can stop this idle load balancing too. Checks added
in fast path are minimized.  Whenever there are busy cpus in the system, there
will be an owner(idle cpu) doing the system wide idle load balancing.

Open items:
1. Intelligent owner selection (like an idle core in a busy package).
2. Merge with rcu's nohz_cpu_mask?

Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]>
---

diff -pNru linux-2.6.20.x86_64/include/linux/sched.h linux/include/linux/sched.h
--- linux-2.6.20.x86_64/include/linux/sched.h   2007-02-10 03:41:27.0 
-0800
+++ linux/include/linux/sched.h 2007-02-16 17:44:08.0 -0800
@@ -237,6 +237,14 @@ extern void sched_init_smp(void);
 extern void init_idle(struct task_struct *idle, int cpu);
 
 extern cpumask_t nohz_cpu_mask;
+#if defined(CONFIG_SMP) && defined(CONFIG_NO_HZ)
+extern int select_nohz_load_balancer(int cpu);
+#else
+static inline int select_nohz_load_balancer(int cpu)
+{
+   return 0;
+}
+#endif
 
 /*
  * Only dump TASK_* tasks. (-1 for all tasks)
diff -pNru linux-2.6.20.x86_64/kernel/sched.c linux/kernel/sched.c
--- linux-2.6.20.x86_64/kernel/sched.c  2007-02-16 16:40:16.0 -0800
+++ linux/kernel/sched.c2007-02-16 17:56:13.0 -0800
@@ -241,6 +241,9 @@ struct rq {
 #ifdef CONFIG_SMP
unsigned long cpu_load[3];
unsigned char idle_at_tick;
+#ifdef CONFIG_NO_HZ
+   unsigned char in_nohz_recently;
+#endif
 #endif
unsigned long long nr_switches;
 
@@ -1169,6 +1172,17 @@ static void resched_task(struct task_str
if (!tsk_is_polling(p))
smp_send_reschedule(cpu);
 }
+
+static void resched_cpu(int cpu)
+{
+   struct rq *rq = cpu_rq(cpu);
+   unsigned long flags;
+
+   if (!spin_trylock_irqsave(>lock, flags))
+   return;
+   resched_task(cpu_curr(cpu));
+   spin_unlock_irqrestore(>lock, flags);
+}
 #else
 static inline void resched_task(struct task_struct *p)
 {
@@ -3067,6 +3081,9 @@ redo:
double_rq_unlock(this_rq, busiest);
local_irq_restore(flags);
 
+   if (nr_moved && this_cpu != smp_processor_id())
+   resched_cpu(this_cpu);
+
/* All tasks on this runqueue were pinned by CPU affinity */
if (unlikely(all_pinned)) {
cpu_clear(cpu_of(busiest), cpus);
@@ -3335,6 +3352,79 @@ static void update_load(struct rq *this_
}
 }
 
+#ifdef CONFIG_NO_HZ
+static struct {
+   int load_balancer;
+   cpumask_t  cpu_mask;
+} nohz cacheline_aligned = {
+   .load_balancer = -1,
+   .cpu_mask = CPU_MASK_NONE,
+};
+
+/*
+ * This routine will try to nominate the ilb (idle load balancing)
+ * owner among the cpus whose ticks are stopped. ilb owner will do the idle
+ * load balancing on behalf of all those cpus. If all the cpus in the system
+ * go into this tickless mode, then there will be no ilb owner (as there is
+ * no need for one) and all the cpus will sleep till the next wakeup event
+ * arrives...
+ *
+ * For the ilb owner, tick is not stopped. And this tick will be used
+ * for idle load balancing. ilb owner will still be part of
+ * nohz.cpu_mask..
+ *
+ * While stopping the tick, this cpu will become the ilb owner if there
+ * is no other owner. And will be the owner till that cpu becomes busy
+ * or if all cpus in the system stop their ticks at which point
+ * there is no need for ilb owner.
+ *
+ * When the ilb owner becomes busy, it nominates another owner, during the
+ * next busy scheduler_tick()
+ */
+int select_nohz_load_balancer(int stop_tick)
+{
+   int cpu = smp_processor_id();
+
+   if (stop_tick) {
+   cpu_set(cpu, nohz.cpu_mask);
+   cpu_rq(cpu)->in_nohz_recently = 1;
+
+   /*
+* If we are going offline and still the leader, give up!
+*/
+   if (cpu_is_offline(cpu) && nohz.load_balancer == cpu) {
+   if (cmpxchg(_balancer,  cpu, -1) != cpu)
+   BUG();
+   return 0;
+   }
+
+   /* time for ilb owner also to sleep */
+   if 

RE: GPL vs non-GPL device drivers

[David Schwartz]

> On 2/16/07, David Schwartz <[EMAIL PROTECTED]> wrote:

> > (See, among other cases, Lexmark. v. Static
> > Controls.) A copyright is not a patent, you can only own
> > something if there
> > are multiple equally good ways to do it and you claim *one* of them.

> Only in a world where "write a Linux module" is a "functional idea." I
> don't think that the legal world in the US is an example of such a
> world, though you clearly do.

I'm not arguing "write a Linux module" is a functional idea. But "write code
so that a graphics card with a X1950 chipset works with a Linux kernel"
certainly is.

Again, see Lexmark v. Static Controls. If "make a toner cartridge that works
with a particular Lexmark printer" is a functional idea, why is "make a
graphics driver that works with a particular Linux kernel" not? What is the
difference you think matters?

DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: GPL vs non-GPL device drivers

[David Schwartz]

> > That's exactly what they're doing. Knowing only the *function* of his
> > program, they are claiming it must obey their licensing terms.
> > They have no
> > idea exactly how he chose to implement that function, but claim
> > they must
> > own it anyway.

> They are not claiming ownership of his code.

When you claim that somoene else's work is a derivative work of yours, that
is precisely what you are doing. You are arguing that they could not have
even created that work without your permission.

> They are claiming
> ownership of THEIR
> code.  V J is taking their code, adding on to it and selling the
> result.  Without
> the GPL, V J cannot legally do this.

Not so. See any of the numerous cases that explain that you cannot own a
function using copyright. They are saying that because V J did X, he *MUST*
be taking their code because there is no other practical way to *do* X. This
is precisely what copyright *DOES* *NOT* *LET* *YOU* *DO*.

> With the GPL, he can
> legally do this IF he
> also gives out the complete source.  I fail to see how anything
> you are saying
> absolves him of this requirement.

The fact that they are claiming rights that are impossible with copyright
and inconsistent with its logic. Copyright covers the one way you chose to
do something out of the many possible ways to do it. To argue "you must have
taken my code because you were able to *DO* X" is arguing you own every
practical way to do X. This is what software patents do, but this is beyond
the scope of copyright.

How can they know he took their code to accomplish a particular function
unless they are claiming they own every way to accomplish that function?
This is precisely what the open source community stands *AGAINST*.
(Ownership of functions.)

DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: GPL vs non-GPL device drivers

[David Schwartz]

> On Thu, Feb 15, 2007 at 04:38:41PM -0800, David Schwartz wrote:

> > Just to be perfectly clear, it is an outrageous claim that *every*
> > *possible* kernel module must be a derivative work of the
> > kernel. Copyright
> > *cannot* protect every possible way to accomplish a particular
> > function (and
> > "a Linux driver for the X800 graphics chipset" is a function).

> This is just your personal opinion.

Umm, no. It's clearly the law. Again, see Lexmark v. Static Controls, among
other cases.

> "derivative work" is a term with many grey areas.
> Does linking create a derivative work?

I don't think that's grey at all. I think it's perfectly clear that linking
cannot create a derivative work. No automated process can -- it takes
creativity to create a derivative work. (That doesn't mean that just because
you can link A to B, a cannot be a derivative work of B or vice verse, of
course. It just means that if A is not a derivative work of B, linking A to
B cannot make it so, nor can the result be a derivative work.)

> Or including the code of one "static inline" function in your binary?

That would be a tricky border case. I wouldn't presume to be able to predict
the result of an inquiry into a case like that.

> There is no border everyone agrees on.

That's not the issue. The fact that we can't agree on precisely where red
ends and orange begins is not a counter-argument to a claim that a
particular thing is *clearly* red.

> And even judges in different jurisdictions might decide differently
> based on different copyright laws.

Sure, in border cases, but not in cases where it's perfectly clear.

> Perhaps some module would be considered legal in the USA and Russia but
> illegal in Germany and China, or the other way round.

I agree. I am mostly talking about US law.

> > Copyright can
> > *only* protect the one possible way you chose to do something
> > out of a large
> > number of equally good possible ways. (See, for example,
> > Lexmark v. Static
> > Controls where courts held that Static Controls could take Lexmark's TLP
> > software because that was the only practical way to make a
> > compatible toner
> > cartridge.)
> >...

> It's always funny seeing people making univeral claims only based on
> laws and court cases that have zero relevance for > 95% of all people...

I cite the case only because it does a good job of explaining the principle.
Copyright cannot allow you to own every practical way of accomplishing
something. It can only allow you to own the one particular way you chose to
do something out of a universe of other possible equally good ways. Only
patent allows you to protect the "best way" or "every way" to perform a
function.

DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 1/2] sched: fix idle load balancing in softirqd context

[Siddha, Suresh B]

Periodic load balancing in recent kernels happen in the softirq.
In certain -rt configurations, these softirqs are handled in softirqd
context. And hence the check for idle processor was always returning
busy (as nr_running > 1).

This patch captures the idle information at the tick and passes this info
to softirq context through an element 'idle_at_tick' in rq.

Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]>
---

diff -pNru linux-2.6.20.x86_64/kernel/sched.c linux/kernel/sched.c
--- linux-2.6.20.x86_64/kernel/sched.c  2007-02-10 03:41:27.0 -0800
+++ linux/kernel/sched.c2007-02-16 16:22:44.0 -0800
@@ -240,6 +240,7 @@ struct rq {
unsigned long raw_weighted_load;
 #ifdef CONFIG_SMP
unsigned long cpu_load[3];
+   unsigned char idle_at_tick;
 #endif
unsigned long long nr_switches;
 
@@ -3350,12 +3351,7 @@ static void run_rebalance_domains(struct
struct rq *this_rq = cpu_rq(this_cpu);
unsigned long interval;
struct sched_domain *sd;
-   /*
-* We are idle if there are no processes running. This
-* is valid even if we are the idle process (SMT).
-*/
-   enum idle_type idle = !this_rq->nr_running ?
-   SCHED_IDLE : NOT_IDLE;
+   enum idle_type idle = this_rq->idle_at_tick ? SCHED_IDLE : NOT_IDLE;
/* Earliest time when we have to call run_rebalance_domains again */
unsigned long next_balance = jiffies + 60*HZ;
 
@@ -3651,20 +3647,21 @@ void scheduler_tick(void)
 {
unsigned long long now = sched_clock();
struct task_struct *p = current;
-   int cpu = smp_processor_id();
+   int cpu = smp_processor_id(), idle_at_tick = idle_cpu(cpu);
struct rq *rq = cpu_rq(cpu);
 
BUG_ON(!irqs_disabled());
 
update_cpu_clock(p, rq, now);
 
-   if (p == rq->idle)
+   if (idle_at_tick)
/* Task on the idle queue */
wake_priority_sleeper(rq);
else
task_running_tick(rq, p);
 #ifdef CONFIG_SMP
update_load(rq);
+   rq->idle_at_tick = idle_at_tick;
if (time_after_eq(jiffies, rq->next_balance))
raise_softirq(SCHED_SOFTIRQ);
 #endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH(Experimental) 1/4] freezer-cpu-hotplug core

[Srivatsa Vaddagiri]

On Fri, Feb 16, 2007 at 10:46:05PM +0300, Oleg Nesterov wrote:
> Instead, we can just clear PF_FROZEN before kthread_should_stop().

That should work too. Thanks!

> I don't claim this is better, but this way we don't need to add a
> subtle change to process.c.

-- 
Regards,
vatsa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH(Experimental) 2/4] Revert changes to workqueue.c

[Srivatsa Vaddagiri]

On Sat, Feb 17, 2007 at 02:59:39AM +0300, Oleg Nesterov wrote:
> In that case (all processes are frozen when workqueue_cpu_callback()
> calls cleanup_workqueue_thread()) I agree, it is better to just use
> kthread_stop/kthread_should_stop.

Great, thanks!

> This also means that probably it won't be convenient to do this change
> "by small steps" as I suggested before.

Yeah, thats what I thought. We will try to split it to the extent
possible in the next iteration.

Thanks for your feedback/review!

-- 
Regards,
vatsa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.21-rc1] ibmebus: Support dynamic addition and removal of adapters

[Joachim Fenkes]

Sylvain Munaut <[EMAIL PROTECTED]> wrote on 15.02.2007 15:11:42:

> Mmmh, I posted a patch that added a common uevent interface for all
> of_device based bus. And that kinda clash with this one.

Oops, I was not aware of this. I had a look at your patch and yes, it's a 
nice
and generic interface. I concur that using your generic function is the 
better
approach.

> But as "ibm,loc_code" is local to this bus it's not handled by my code.
> Is it necessary to match the correct driver ?

The intention of adding the location code was to include a device property
into the environment that's unique to each device. Actually, the DEVPATH 
variable
provides exactly this: For ebus devices, it points to the ebus device 
itself,
which natually is unique.

If a userspace tool really needs the location code, the "devspec" 
attribute of
the ebus device will point it to the device tree node, which in turn 
contains the
location code property.

So I think there's nothing preventing me from using your function. Thanks 
for
pointing this out.

Regards,
  Joachim

---
Joachim Fenkes  --  eHCA Linux Driver Developer and Hardware Tamer 
extraordinaire
IBM Deutschland Entwicklung GmbH  --  Dept. 3627 (I/O Firmware Development 
2)
Schoenaicher Strasse 220  --  71032 Boeblingen  --  Germany
eMail: [EMAIL PROTECTED]  --  Phone: +49 7031 16 1239 

Vorsitzender des Aufsichtsrats: Johann Weihen  --  Geschäftsführung: 
Herbert Kircher
Sitz der Gesellschaft: Böblingen  --  Registergericht: Amtsgericht 
Stuttgart, HRB 243294
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20.git regression: 'PCI: add the sysfs driver name to all modules' causes hard hang on boot

[Markus Rechberger]

On 2/17/07, Greg KH <[EMAIL PROTECTED]> wrote:

On Sat, Feb 17, 2007 at 02:38:08AM +0100, Mike Galbraith wrote:
> On Fri, 2007-02-16 at 14:36 -0800, Greg KH wrote:
> > On Fri, Feb 16, 2007 at 10:55:10AM +0100, Mike Galbraith wrote:
> > > Greetings,
> > >
> > > Per $subject, git.yesterday hangs hard on boot here. A git bisect
> > > fingered the commit below, which I verified via git bisect reset; git
> > > revert -n 725522b5453dd680412f2b6463a988e4fd148757, after which box
> > > boots fine.  (well, I hope I verified... i'm git-ignorant)
> >
> > If you change CONFIG_SYSFS_DEPRECATED to Y, does that solve the problem?
>
> It's already set.

It's not set in the config file you sent to me and the list :)



I'm having a hard lockup to when I fire up xmms in X (maybe some other
apps too) I'm bisecting at the moment.
CONFIG_SYSFS_DEPRECIATED is set to Y here too, so I might have another
problem here.. let's see what bisecting will show up..

Markus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[git patches] more IDE updates

[Bartlomiej Zolnierkiewicz]

Contains: IRQ-ack fix for ICH chipsets (Albert Lee), ide-floppy unformatted
media fix (Alan Cox), more fixes for IDE PCI drivers (Sergei Shtylyov),
new driver for Toshiba Cell Reference Board (Kou Ishizaki ) and a bunch of rather obvious cleanups/improvements (me).

There are still some bugfix patches in my tree which should go into 2.6.21
but since they are quite fresh and there have already been a lot of IDE
changes since the merge window was opened I will wait for -rc1 to push
them upstream.

[ Andrew, IDE quilt tree has already been updated wrt to this update ]

Linus, please pull from:

master.kernel.org:/pub/scm/linux/kernel/git/bart/ide-2.6.git/

to receive the following updates:

 drivers/ide/Kconfig|8 
 drivers/ide/Makefile   |1 
 drivers/ide/arm/icside.c   |   25 -
 drivers/ide/arm/rapide.c   |2 
 drivers/ide/cris/ide-cris.c|   34 -
 drivers/ide/h8300/ide-h8300.c  |4 
 drivers/ide/ide-cd.c   |   44 --
 drivers/ide/ide-disk.c |   14 
 drivers/ide/ide-dma.c  |  105 +++--
 drivers/ide/ide-floppy.c   |   29 -
 drivers/ide/ide-io.c   |   15 
 drivers/ide/ide-iops.c |   34 -
 drivers/ide/ide-lib.c  |   20 
 drivers/ide/ide-probe.c|4 
 drivers/ide/ide-tape.c |   12 
 drivers/ide/ide.c  |   24 -
 drivers/ide/legacy/buddha.c|2 
 drivers/ide/legacy/gayle.c |2 
 drivers/ide/legacy/ht6560b.c   |   14 
 drivers/ide/legacy/macide.c|2 
 drivers/ide/legacy/q40ide.c|2 
 drivers/ide/mips/au1xxx-ide.c  |   41 --
 drivers/ide/mips/swarm.c   |2 
 drivers/ide/pci/aec62xx.c  |   32 -
 drivers/ide/pci/alim15x3.c |   15 
 drivers/ide/pci/amd74xx.c  |5 
 drivers/ide/pci/atiixp.c   |   41 --
 drivers/ide/pci/cmd64x.c   |   47 --
 drivers/ide/pci/cs5520.c   |5 
 drivers/ide/pci/cs5530.c   |   41 --
 drivers/ide/pci/cs5535.c   |   19 
 drivers/ide/pci/cy82c693.c |   33 -
 drivers/ide/pci/hpt34x.c   |   42 --
 drivers/ide/pci/hpt366.c   |   24 -
 drivers/ide/pci/it8213.c   |   14 
 drivers/ide/pci/it821x.c   |   14 
 drivers/ide/pci/jmicron.c  |   14 
 drivers/ide/pci/ns87415.c  |   13 
 drivers/ide/pci/opti621.c  |   63 +--
 drivers/ide/pci/pdc202xx_new.c |   28 -
 drivers/ide/pci/pdc202xx_old.c |  104 +
 drivers/ide/pci/piix.c |  119 +++--
 drivers/ide/pci/sc1200.c   |   11 
 drivers/ide/pci/serverworks.c  |   59 --
 drivers/ide/pci/sgiioc4.c  |  125 ++
 drivers/ide/pci/siimage.c  |  113 ++---
 drivers/ide/pci/sis5513.c  |   59 --
 drivers/ide/pci/sl82c105.c |   39 -
 drivers/ide/pci/slc90e66.c |   22 -
 drivers/ide/pci/tc86c001.c |   46 --
 drivers/ide/pci/triflex.c  |   24 -
 drivers/ide/pci/trm290.c   |   42 --
 drivers/ide/pci/via82cxxx.c|5 
 drivers/ide/ppc/pmac.c |   16 
 drivers/ide/ppc/scc_pata.c |  831 +
 drivers/scsi/ide-scsi.c|8 
 include/linux/ide.h|   28 -
 57 files changed, 1523 insertions(+), 1018 deletions(-)

Alan Cox (1):
  ide-floppy: Fix unformatted media crash

Albert Lee (2):
  ide: clear bmdma status in ide_intr() for ICHx controllers (revised #4)
  ide: remove clearing bmdma status from cdrom_decode_status() (rev #4)

Bartlomiej Zolnierkiewicz (23):
  hpt34x: hpt34x_tune_chipset() (->speedproc) fix
  atiixp/jmicron/triflex: fix PIO fallback
  pdc202xx_old: remove dead code
  au1xxx-ide: remove dead code
  trm290: remove redundant CONFIG_BLK_DEV_IDEDMA #ifdef-s
  hpt366: remove redundant check from init_dma_hpt366()
  cs5530: small cleanup
  svwks: small cleanup
  piix: cleanup
  sis5513: sis5513_config_xfer_rate() cleanup
  ide: remove write-only ide_pio_data_t.blacklisted
  ide: remove write-only ide_hwif_t.no_dsc flag
  ide: remove ide_pci_device_t tables with only one entry
  ide: remove ide_drive_t.usage
  ide: unexport ide_set_xfer_rate() (v2)
  ide: add ide_use_fast_pio() helper (v3)
  ide: use PIO/MMIO operations directly where possible (v2)
  ide: convert ide_hwif_t.mmio into flag (v2)
  ide: disable DMA in ->ide_dma_check for "no IORDY" case (v2)
  sgiioc4: fix sgiioc4_ide_dma_check() to enable/disable DMA properly
  ide: add ide_set_dma() helper (v2)
  ide: make ide_hwif_t.ide_dma_{host_off,off_quietly} void (v2)
  ide: make ide_hwif_t.ide_dma_host_on void (v2)

Kou Ishizaki (1):
  drivers/ide: PATA driver for Celleb

Sergei Shtylyov (3):
  siimage: PIO1/2 taskfile transfer overclocking fix
  pdc202xx_old: fix PIO mode setup
  sl82c105: DMA support fixes

...and once again patch is too big for the mailing list
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ck] Re: 2.6.20-ck1

[michael chang]

On 2/16/07, Con Kolivas <[EMAIL PROTECTED]> wrote:

I'm thru with bashing my head against the wall.


I do hope this post isn't in any way redundant, but from what I can
see, this has never been suggested... (someone please do enlighten me
if I'm wrong.)

Has anyone tried booting a kernel with the various patches in question
with a mem=###M boot flag (maybe mem=96M or some other "insanely low
number" ?) to make the kernel think it has less memory than is
physically available (and then compare to vanilla with the same
flags)? It might more clearly demonstrate the effects of Con's patches
when the kernel thinks (or knows) it has relatively little memory
(since many critics, from what I can tell, have quite a bit of memory
on their systems for their workloads).

Just my two cents.

--
~Mike
- Just the crazy copy cat.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.20-git: undefined reference to `smp_call_function_single'

[Len Brown]

Yes, an obscure .config, but it used to build before today:

kernel/built-in.o: In function `tick_broadcast_on_off':
(.text+0x1b6f0): undefined reference to `smp_call_function_single'
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.20
# Fri Feb 16 19:08:20 2007
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
# CONFIG_UTS_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_CPUSETS is not set
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y

#
# Block layer
#
CONFIG_BLOCK=y
CONFIG_LBD=y
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_SMP=y
# CONFIG_X86_PC is not set
# CONFIG_X86_ELAN is not set
CONFIG_X86_VOYAGER=y
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
CONFIG_M686=y
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MCORE2 is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_PPRO_FENCE=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_NR_CPUS=8
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_BKL=y
CONFIG_VM86=y
CONFIG_TOSHIBA=y
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
CONFIG_MICROCODE=y
CONFIG_MICROCODE_OLD_INTERFACE=y
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
# CONFIG_NOHIGHMEM is not set
# CONFIG_HIGHMEM4G is not set
CONFIG_HIGHMEM64G=y
CONFIG_PAGE_OFFSET=0xC000
CONFIG_HIGHMEM=y
CONFIG_X86_PAE=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_RESOURCES_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_HIGHPTE=y
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_SECCOMP=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
# CONFIG_KEXEC is 

Re: 2.6.20.git regression: 'PCI: add the sysfs driver name to all modules' causes hard hang on boot

[Greg KH]

On Sat, Feb 17, 2007 at 02:38:08AM +0100, Mike Galbraith wrote:
> On Fri, 2007-02-16 at 14:36 -0800, Greg KH wrote:
> > On Fri, Feb 16, 2007 at 10:55:10AM +0100, Mike Galbraith wrote:
> > > Greetings,
> > > 
> > > Per $subject, git.yesterday hangs hard on boot here. A git bisect
> > > fingered the commit below, which I verified via git bisect reset; git
> > > revert -n 725522b5453dd680412f2b6463a988e4fd148757, after which box
> > > boots fine.  (well, I hope I verified... i'm git-ignorant)
> > 
> > If you change CONFIG_SYSFS_DEPRECATED to Y, does that solve the problem?
> 
> It's already set.

It's not set in the config file you sent to me and the list :)

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20.git regression: 'PCI: add the sysfs driver name to all modules' causes hard hang on boot

[Mike Galbraith]

On Fri, 2007-02-16 at 14:36 -0800, Greg KH wrote:
> On Fri, Feb 16, 2007 at 10:55:10AM +0100, Mike Galbraith wrote:
> > Greetings,
> > 
> > Per $subject, git.yesterday hangs hard on boot here. A git bisect
> > fingered the commit below, which I verified via git bisect reset; git
> > revert -n 725522b5453dd680412f2b6463a988e4fd148757, after which box
> > boots fine.  (well, I hope I verified... i'm git-ignorant)
> 
> If you change CONFIG_SYSFS_DEPRECATED to Y, does that solve the problem?

It's already set.

> If not, can you press alt-sysrq-T and send us the list of the tasks so
> that we can try to figure out what is hanging here?

Box is ding-dong-dead.

I'll fiddle with it.  (pretty darn innocuous looking change...)

-Mike

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] killing the NR_IRQS arrays.

[Arnd Bergmann]

On Friday 16 February 2007 23:37, Benjamin Herrenschmidt wrote:
> You might want to have a look at the powerpc API with it's remaping
> capabilities. It's very nice for handling multiple domain spaces. It
> might be of some use for you.

I don't consider the powerpc virtual IRQs a solution for the problem.
While I believe you did the right thing for powerpc with generalizing
this over all its platforms, it really isn't more than a workaround
for the problem that we can't deal well with the static irq_desc
array.

When that problem is now getting worse on other architectures, we
should try to get it right on all of them, rather than spreading
the workaround further.

Arnd <><
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

CAP_NET_BIND_SERVICE checking in inet_bind vs socket_bind

[Simon Arlott]

Why does inet_bind (instead of socket_bind) check that ports below 1024 require 
CAP_NET_BIND_SERVICE?
Couldn't this check be moved to the dummy socket_bind so that the behaviour can 
be changed by a security module?

---

diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index cf358c8..d75a2c5 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -431,9 +431,11 @@ int inet_bind(struct socket *sock, struc
goto out;
 
snum = ntohs(addr->sin_port);
+#ifndef CONFIG_SECURITY_NETWORK
err = -EACCES;
if (snum && snum < PROT_SOCK && !capable(CAP_NET_BIND_SERVICE))
goto out;
+#endif
 
/*  We keep a pair of addresses. rcv_saddr is the one
 *  used by hash lookups, and saddr is used for transmit.
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index 3585d8f..768989d 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -262,8 +262,10 @@ int inet6_bind(struct socket *sock, stru
return -EINVAL;
 
snum = ntohs(addr->sin6_port);
+#ifndef CONFIG_SECURITY_NETWORK
if (snum && snum < PROT_SOCK && !capable(CAP_NET_BIND_SERVICE))
return -EACCES;
+#endif
 
lock_sock(sk);
 
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
diff --git a/security/dummy.c b/security/dummy.c
index 558795b..1315b19 100644
--- a/security/dummy.c
+++ b/security/dummy.c
@@ -29,6 +29,8 @@ #include 
 #include 
 #include 
 
+#include 
+
 static int dummy_ptrace (struct task_struct *parent, struct task_struct *child)
 {
return 0;
@@ -718,6 +720,26 @@ static int dummy_socket_post_create (str
 static int dummy_socket_bind (struct socket *sock, struct sockaddr *address,
  int addrlen)
 {
+   switch (address->sa_family) {
+#ifdef INET
+   case PF_INET: {
+   struct sockaddr_in *addr = (struct sockaddr_in 
*)address;
+   unsigned short snum;
+   snum = ntohs((addr->sin_port));
+   if (snum && snum < PROT_SOCK && 
!capable(CAP_NET_BIND_SERVICE))
+   return -EACCES;
+   break;
+   }
+   case PF_INET6: {
+   struct sockaddr_in6 *addr = (struct sockaddr_in6 
*)address;
+   unsigned short snum;
+   snum = ntohs(addr->sin6_port);
+   if (snum && snum < PROT_SOCK && 
!capable(CAP_NET_BIND_SERVICE))
+   return -EACCES;
+   break;
+   }
+#endif
+   }
return 0;
 }
 

-- 
Simon Arlott



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] nfs: init req_lock in nfs_alloc_inode

[Andrew Morton]

On Fri, 16 Feb 2007 11:05:32 -0600
[EMAIL PROTECTED] (Olof Johansson) wrote:

> Seems like req_lock is never initialized. CONFIG_DEBUG_SPINLOCK reported:
> 
> BUG: spinlock bad magic on CPU#0, mount/1073
>  lock: c0007fdca108, .magic: , .owner: /24576, .owner_cpu: 0
> Call Trace:
> [C0007E913750] [C00107B4] .show_stack+0x54/0x1f0 (unreliable)
> [C0007E913800] [C01D2234] .spin_bug+0xa4/0x120
> [C0007E913890] [C01D247C] ._raw_spin_lock+0xdc/0x1d0
> [C0007E913930] [C04DF990] ._spin_lock+0x10/0x30
> [C0007E9139B0] [C017623C] .nfs_sync_mapping_wait+0xac/0x310
> [C0007E913AA0] [C0176F18] .nfs_sync_mapping_range+0x98/0x110
> [C0007E913B80] [C016CAA0] .nfs_getattr+0x40/0xf0
> [C0007E913C20] [C00BE668] .vfs_getattr+0x38/0x70
> [C0007E913CA0] [C00BF05C] .vfs_fstat+0x3c/0x70
> [C0007E913D30] [C00BF0B8] .sys_fstat64+0x28/0x60
> [C0007E913E30] [C0008608] syscall_exit+0x0/0x40
> 
> 
> Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
> 
> ---
> 
> Trond, is your MAINTAINERS entry up to date? Seems like you mostly post
> from @netapp.com these days.
> 
> 
> Index: linux-2.6/fs/nfs/inode.c
> ===
> --- linux-2.6.orig/fs/nfs/inode.c
> +++ linux-2.6/fs/nfs/inode.c
> @@ -1123,6 +1123,7 @@ struct inode *nfs_alloc_inode(struct sup
>   nfsi->flags = 0UL;
>   nfsi->cache_validity = 0UL;
>   nfsi->cache_change_attribute = jiffies;
> + nfsi->req_lock = SPIN_LOCK_UNLOCKED;
>  #ifdef CONFIG_NFS_V3_ACL
>   nfsi->acl_access = ERR_PTR(-EAGAIN);
>   nfsi->acl_default = ERR_PTR(-EAGAIN);

req_lock is initialsied in fs/nfs/inode.c:init_once().

What kernel version were you using?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.20-mm1 USB-related OOPS

[Berck E. Nash]

I get the following OOPS on boot, presumably connected with USB driver
loading.  I've attached the entire log.  Please CC on replies as I'm not
subscribed.

[  149.525742] Unable to handle kernel NULL pointer dereference at
0008 RIP:
[  149.531302]  [] :cdc_acm:acm_probe+0x1dd/0x741
[  149.539958] PGD 3d248067 PUD 3d23c067 PMD 0
[  149.544431] Oops:  [1] PREEMPT SMP
[  149.548475] last sysfs file: /class/net/lo/operstate
[  149.553510] CPU 0
[  149.555618] Modules linked in: cdc_acm snd_rtctimer w83627ehf eeprom
i2c_isa nvidia(P) usb_storage usbhid 8139cp snd_hda_intel snd_hda_codec
snd_pcm_oss snd_pcm snd_mixer_oss snd_seq_dummy snd_seq_oss
snd_seq_midi_event snd_seq snd_timer snd_seq_device snd 8139too uhci_hcd
mii soundcore snd_page_alloc i2c_i801 evdev usbcore i2c_core floppy
[  149.587337] Pid: 1620, comm: modprobe Tainted: P   2.6.20-mm1 #3
[  149.593785] RIP: 0010:[]  []
:cdc_acm:acm_probe+0x1dd/0x741
[  149.602650] RSP: 0018:81003df29c98  EFLAGS: 00010246
[  149.608045] RAX: 81003eb14800 RBX: 81003eb14820 RCX:
81003eb21008
[  149.615278] RDX: 81003eb14800 RSI:  RDI:

[  149.622507] RBP:  R08: 0001 R09:
0d80
[  149.629730] R10:  R11: c219a7f8 R12:
0d80
[  149.636960] R13: 81003f555800 R14:  R15:
81003eb14800
[  149.644183] FS:  2abc668716d0() GS:80544000()
knlGS:
[  149.652393] CS:  0010 DS:  ES:  CR0: 8005003b
[  149.658217] CR2: 0008 CR3: 3d25d000 CR4:
06e0
[  149.665458] Process modprobe (pid: 1620, threadinfo 81003df28000,
task 81003eeb0950)
[  149.674014] Stack:  81003d21af20 81003eb14800
81003edf3418 81003d21af20
[  149.682317]  fff4 81003d4e3820 00ff804db922
0001
[  149.689981]  00100db0 81003d21af20 8801cbe5
81003eb14820
[  149.697455] Call Trace:
[  149.700194]  [] :usbcore:usb_match_one_id+0x26/0x84
[  149.706742]  [] :usbcore:usb_probe_interface+0x7d/0xa5
[  149.713544]  [] driver_probe_device+0xf6/0x17f
[  149.719654]  [] __driver_attach+0x0/0x93
[  149.725230]  [] __driver_attach+0x5a/0x93
[  149.730893]  [] bus_for_each_dev+0x43/0x6e
[  149.736644]  [] bus_add_driver+0x6b/0x18d
[  149.742310]  [] :usbcore:usb_register_driver+0x85/0xeb
[  149.749113]  [] :cdc_acm:acm_init+0xcc/0x105
[  149.755037]  [] sys_init_module+0x1572/0x16d2
[  149.761058]  [] system_call+0x7e/0x83
[  149.766361]
[  149.767898]
[  149.767898] Code: 49 8b 46 08 80 78 05 0a 74 17 49 8b 47 08 80 78 05
0a 0f 85
[  149.777661] RIP  [] :cdc_acm:acm_probe+0x1dd/0x741
[  149.784146]  RSP 
[  149.787694] CR2: 0008
[0.00] Linux version 2.6.20-mm1 ([EMAIL PROTECTED]) (gcc version 4.1.2 
20061115 (prerelease) (Debian 4.1.1-21)) #3 SMP PREEMPT Fri Feb 16 17:31:24 MST 
2007
[0.00] Command line: root=/dev/sdc1 ro console=tty0 
console=ttyS0,115200n8 BOOT_IMAGE=vmlinuz
[0.00] BIOS-provided physical RAM map:
[0.00]  BIOS-e820:  - 0009fc00 (usable)
[0.00]  BIOS-e820: 0009fc00 - 000a (reserved)
[0.00]  BIOS-e820: 000e4000 - 0010 (reserved)
[0.00]  BIOS-e820: 0010 - 3ff8 (usable)
[0.00]  BIOS-e820: 3ff8 - 3ff8e000 (ACPI data)
[0.00]  BIOS-e820: 3ff8e000 - 3ffe (ACPI NVS)
[0.00]  BIOS-e820: 3ffe - 4000 (reserved)
[0.00]  BIOS-e820: ffb0 - 0001 (reserved)
[0.00] end_pfn_map = 1048576
[0.00] DMI 2.4 present.
[0.00] ACPI: RSDP 000FAF20, 0024 (r2 ACPIAM)
[0.00] ACPI: XSDT 3FF80100, 0064 (r1 NEC  1000724 MSFT  
 97)
[0.00] ACPI: FACP 3FF80290, 00F4 (r3 A_M_I_ OEMFACP   1000724 MSFT  
 97)
[0.00] ACPI: DSDT 3FF80590, 9560 (r1  A0543 A05430000 INTL 
20060113)
[0.00] ACPI: FACS 3FF8E000, 0040
[0.00] ACPI: APIC 3FF80390, 0080 (r1 A_M_I_ OEMAPIC   1000724 MSFT  
 97)
[0.00] ACPI: SLIC 3FF80410, 0176 (r1 NEC  1000724 MSFT  
 97)
[0.00] ACPI: OEMB 3FF8E040, 0066 (r1 A_M_I_ AMI_OEM   1000724 MSFT  
 97)
[0.00] ACPI: HPET 3FF89AF0, 0038 (r1 A_M_I_ OEMHPET   1000724 MSFT  
 97)
[0.00] ACPI: MCFG 3FF89B30, 003C (r1 A_M_I_ OEMMCFG   1000724 MSFT  
 97)
[0.00] ACPI: SSDT 3FF8E0B0, 01C6 (r1AMI   CPU1PM1 INTL 
20060113)
[0.00] ACPI: SSDT 3FF8E280, 013A (r1AMI   CPU2PM1 INTL 
20060113)
[0.00] Zone PFN ranges:
[0.00]   DMA 0 -> 4096
[0.00]   DMA324096 ->  1048576
[0.00]   Normal1048576 ->  1048576
[0.00] early_node_map[2] active PFN ranges
[0.00] 0:0 ->  159
[0.00] 

Re: 2.6.20-ck1

[Con Kolivas]

On Saturday 17 February 2007 11:53, Chuck Ebbert wrote:
> Con Kolivas wrote:
> > mm-filesize_dependant_lru_cache_add.patch
>
> I like it.

Thanks :-)

> Is any of this stuff ever going to be merged?

See the last paragraph here:
http://lkml.org/lkml/2007/2/9/112

I'm thru with bashing my head against the wall.

-- 
-ck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add .splice_read to sockets?

[Jens Axboe]

On Sat, Feb 17 2007, Paul P Komkoff Jr wrote:
> Hi!
> 
> Is there any plans to make splice(socket, ..., pipe, ...) work?

It's a work in-progress, latest effort is to import and attempt to fix
the stuff that Intel initially posted some months ago. See the
splice-net branch of the block git repo.

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: loosen dependancy on rtc cmos

[David Brownell]

On Thursday 15 February 2007 9:12 pm, David Brownell wrote:
> On Thursday 15 February 2007 8:38 pm, Len Brown wrote:
> 
> > So I've taken Andi's advice and checked in the patches below.
> 
> OK; that simplifies things for me, good!  I can discard that patch
> (broken by Andi's pcspkr change anyway), stop worring about whether
> most folk will even see that driver, and make time to look at the
> ACPI hooks for RTC wakeup, instead.  :)

Which, by the way, means that folk with pre-ACPI systems aren't
going to be able to use this driver until someone else provides
an updated patch creating an "rtc_cmos" platform device.

Or on the more modern end of things ... I suspect PCs using
Linux-BIOS won't do PNPACPI either, and they will also need
that platform device before using this driver.

What do the MiniMac systems do?  At one time I thought they
were ACPI-free.

- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] 9p: add write-cache support to loose cache mode (take 4)

[Andrew Morton]

On Fri, 16 Feb 2007 18:46:59 -0600
Eric Van Hensbergen <[EMAIL PROTECTED]> wrote:

> Loose cache mode was added primarily to asssist exclusive, read-only
> mounts (like venti) -- however, there is also a case for using loose
> write cacheing in support of read/write exclusive mounts.  This feature
> is linked to the loose cache option and is disabled by default.
> 
> This code adds the necessary code to support writes through the page
> cache.  Write caches are not used for synthetic files or for files opened
> in APPEND mode.
> 

Me again ;)

> +int v9fs_prepare_write(struct file *file, struct page *page,
> +unsigned from, unsigned to)
> +{
> + if(!PageUptodate(page)) {
> + if (to - from != PAGE_CACHE_SIZE) {
> + void *kaddr = kmap_atomic(page, KM_USER0);
> + memset(kaddr, 0, from);
> + memset(kaddr + to, 0, PAGE_CACHE_SIZE - to);
> + flush_dcache_page(page);
> + kunmap_atomic(kaddr, KM_USER0);
> + }
> + if ((file->f_flags & O_ACCMODE) != O_WRONLY)
> + v9fs_vfs_readpage_worker(file, page);
> + }
> +
> + return 0;
> +}

Seems strange to memset part of the page and to then go and fill the page
in from backing store.  Perhaps some optimisation is possible here?

And did the error from v9fs_vfs_readpage_worker() just get lost?

> +/**
> + * v9fs_commit_write - prepare for mmap or page-cache I/O
> + *
> + * @file: file being read

"written"

> + * @page: structure to page
> + * @offset: starting offset
> + * @to: ending offset
> + *
> + */
> +
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20-ck1

[Chuck Ebbert]

Con Kolivas wrote:

> mm-filesize_dependant_lru_cache_add.patch

I like it.

Is any of this stuff ever going to be merged?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 05/14] syslets: core code

[Davide Libenzi]

On Thu, 15 Feb 2007, Ingo Molnar wrote:

> + spin_lock(>lock);
> +
> + new_async_thread = pick_ready_cachemiss_thread(ah);
> + if (!new_async_thread)
> + goto out_unlock;
> +
> + async_ready = t->async_ready;
> + WARN_ON(!async_ready);
> + t->async_ready = NULL;
> +
> + new_task = new_async_thread->task;
> +
> + move_user_context(new_task, t);

Since I lost the email where you were describing the todo list, I'll hook 
into this one.
I haven't seen you mentioning it, but at least TID and signal handling 
need to be swapped to. So it'd be better to have a generic 
move_user_context() that does system independent work, and an 
arch_move_user_context() that takes care of system dependent stuff (that 
is called by move_user_context()).



- Davide


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 3/5] scsi: megaraid_sas - throttle io if FW is busy

[Patro, Sumant]

Hello James,

It is difficult to know when the device will go into a state
where it is not able to process cmds within timeout period consistently.
Many factors may be contributing for the device to get into this state. 
Reducing can_queue may help but the difficult part is when does
the can_queue value be restored to the original value. Because, the
device may come back to normal functioning after some time. Also
reducing it to a optimum value that will work for all possible cases is
a challenge.

In a typical setup the throttle io code may not get executed. It
is required only when it has not been able to complete cmds more than 2
times within timeout period.

Regards,

Sumant

-Original Message-
From: James Bottomley [mailto:[EMAIL PROTECTED] 
Sent: Friday, February 16, 2007 9:51 AM
To: Patro, Sumant
Cc: [EMAIL PROTECTED]; linux-scsi@vger.kernel.org;
linux-kernel@vger.kernel.org; Kolli, Neela; Yang, Bo
Subject: RE: [PATCH 3/5] scsi: megaraid_sas - throttle io if FW is busy

On Thu, 2007-02-15 at 19:53 -0700, Patro, Sumant wrote:
> Hello James,
> 
>   I re-submitted the patch yesterday with the "space" issue fixed 
> (adhering to coding guideline).
> 
>   I will check for alternative to calculate the time driver have
been 
> sending host busy to OS. Will check with time_before() as you have 
> suggested.
> 
>   Throttling from megasas_generic_reset() handler did not help.
> megaraid does not have feature to abort cmds. So, in the generic reset

> routine, the driver just waits for cmd completion by FW. These 
> timed-out cmds gets retried by mid-layer with "retries" incremented by
1.
> Eventually we see retries equals max_allowed followed by SCSI error 
> with "DRIVER_TIMEOUT".

That's rather what worries me.  When the error handler activates (which
it will on the first timeout), it waits for all commands to complete or
time out before running.  Your reset handler does nothing other than
wait for the firmware to complete the commands (now uselessly), so we
now wait for the entire firmware command queue to drain, then you tell
the mid layer everything is OK, so it loads you up again with all the
commands plus a few test unit readies for good measure, then you
throttle.

You really want to catch the device going into this condition and do
something at that point ... prime candidate would be lowering the
can_queue depth to get fewer commands transiting the firmware.

James


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 9p: add write-cache support to loose cache mode (take 4)

[Eric Van Hensbergen]

Loose cache mode was added primarily to asssist exclusive, read-only
mounts (like venti) -- however, there is also a case for using loose
write cacheing in support of read/write exclusive mounts.  This feature
is linked to the loose cache option and is disabled by default.

This code adds the necessary code to support writes through the page
cache.  Write caches are not used for synthetic files or for files opened
in APPEND mode.

Signed-of-by: Eric Van Hensbergen <[EMAIL PROTECTED]>
---
 fs/9p/9p.h|2 +-
 fs/9p/conv.c  |   18 +-
 fs/9p/conv.h  |2 +-
 fs/9p/fcall.c |   10 ++-
 fs/9p/fid.c   |   16 +++---
 fs/9p/fid.h   |2 +-
 fs/9p/v9fs_vfs.h  |2 +
 fs/9p/vfs_addr.c  |  173 +---
 fs/9p/vfs_dir.c   |2 +-
 fs/9p/vfs_file.c  |   61 ++
 fs/9p/vfs_inode.c |   20 +-
 fs/9p/vfs_super.c |3 +-
 12 files changed, 265 insertions(+), 46 deletions(-)

diff --git a/fs/9p/9p.h b/fs/9p/9p.h
index 94e2f92..6f8edf0 100644
--- a/fs/9p/9p.h
+++ b/fs/9p/9p.h
@@ -370,6 +370,6 @@ int v9fs_t_read(struct v9fs_session_info *v9ses, u32 fid,
u64 offset, u32 count, struct v9fs_fcall **rcall);
 
 int v9fs_t_write(struct v9fs_session_info *v9ses, u32 fid, u64 offset,
-u32 count, const char __user * data,
+u32 count, const char __user * data, char * kdata,
 struct v9fs_fcall **rcall);
 int v9fs_printfcall(char *, int, struct v9fs_fcall *, int);
diff --git a/fs/9p/conv.c b/fs/9p/conv.c
index a3ed571..9bb075a 100644
--- a/fs/9p/conv.c
+++ b/fs/9p/conv.c
@@ -458,6 +458,15 @@ v9fs_put_user_data(struct cbuf *bufp, const char __user * 
data, int count,
return copy_from_user(*pdata, data, count);
 }
 
+static int
+v9fs_put_kernel_data(struct cbuf *bufp, char * kdata, int count,
+  unsigned char **pdata)
+{
+   *pdata = buf_alloc(bufp, count);
+   memcpy(*pdata, kdata, count);
+   return 0;
+}
+
 static void
 v9fs_put_wstat(struct cbuf *bufp, struct v9fs_wstat *wstat,
   struct v9fs_stat *stat, int statsz, int extended)
@@ -723,7 +732,7 @@ struct v9fs_fcall *v9fs_create_tread(u32 fid, u64 offset, 
u32 count)
 }
 
 struct v9fs_fcall *v9fs_create_twrite(u32 fid, u64 offset, u32 count,
- const char __user * data)
+ const char __user * data, char * kdata)
 {
int size, err;
struct v9fs_fcall *fc;
@@ -738,7 +747,12 @@ struct v9fs_fcall *v9fs_create_twrite(u32 fid, u64 offset, 
u32 count,
v9fs_put_int32(bufp, fid, >params.twrite.fid);
v9fs_put_int64(bufp, offset, >params.twrite.offset);
v9fs_put_int32(bufp, count, >params.twrite.count);
-   err = v9fs_put_user_data(bufp, data, count, >params.twrite.data);
+   if(data)
+   err = v9fs_put_user_data(bufp, data, count,
+   >params.twrite.data);
+   else
+   err = v9fs_put_kernel_data(bufp, kdata, count,
+   >params.twrite.data);
if (err) {
kfree(fc);
fc = ERR_PTR(err);
diff --git a/fs/9p/conv.h b/fs/9p/conv.h
index dd5b6b1..8091672 100644
--- a/fs/9p/conv.h
+++ b/fs/9p/conv.h
@@ -42,7 +42,7 @@ struct v9fs_fcall *v9fs_create_tcreate(u32 fid, char *name, 
u32 perm, u8 mode,
char *extension, int extended);
 struct v9fs_fcall *v9fs_create_tread(u32 fid, u64 offset, u32 count);
 struct v9fs_fcall *v9fs_create_twrite(u32 fid, u64 offset, u32 count,
-   const char __user *data);
+   const char __user *data, char *kdata);
 struct v9fs_fcall *v9fs_create_tclunk(u32 fid);
 struct v9fs_fcall *v9fs_create_tremove(u32 fid);
 struct v9fs_fcall *v9fs_create_tstat(u32 fid);
diff --git a/fs/9p/fcall.c b/fs/9p/fcall.c
index dc336a6..ca77839 100644
--- a/fs/9p/fcall.c
+++ b/fs/9p/fcall.c
@@ -367,7 +367,7 @@ v9fs_t_read(struct v9fs_session_info *v9ses, u32 fid, u64 
offset,
int ret;
struct v9fs_fcall *tc, *rc;
 
-   dprintk(DEBUG_9P, "fid %d offset 0x%llux count 0x%x\n", fid,
+   dprintk(DEBUG_9P, "fid %d offset 0x%llx count 0x%x\n", fid,
(long long unsigned) offset, count);
 
tc = v9fs_create_tread(fid, offset, count);
@@ -393,21 +393,23 @@ v9fs_t_read(struct v9fs_session_info *v9ses, u32 fid, u64 
offset,
  * @fid: fid to write to
  * @offset: offset to start write at
  * @count: how many bytes to write
+ * @data: userspace data
+ * @kdata: kernelspace data
  * @fcall: pointer to response fcall
  *
  */
 
 int
 v9fs_t_write(struct v9fs_session_info *v9ses, u32 fid, u64 offset, u32 count,
-   const char __user *data, struct v9fs_fcall **rcp)
+   const char __user *data, char *kdata, struct v9fs_fcall **rcp)
 {
int ret;
struct v9fs_fcall *tc, *rc;
 
-   dprintk(DEBUG_9P, "fid %d offset 0x%llux count 0x%x\n", fid,
+   

Re: [uml-devel] x86_64: fix 2.6.18 regression - PTRACE_OLDSETOPTIONS should be accepted

[Jeff Dike]

On Sat, Feb 17, 2007 at 01:04:35AM +0100, Blaisorblade wrote:
> Which kernel? I've not yet tested 2.6.20. I'll try debugging this 
> subsequently.

2.6.20-rc6-mm3 on 2.6.20 + patches works for me.

Jeff

-- 
Work email - jdike at linux dot intel dot com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.21-rc1] ibmebus: Support dynamic addition and removal of adapters

[Joachim Fenkes]

John Rose <[EMAIL PROTECTED]> wrote on 15.02.2007 14:57:37:

> Looks good.  Questions: how can the user space tools verify the success
> of an add or remove? 

If the probe operation succeeds, the respective device will show up 
beneath
/sys/bus/ibmebus/devices.
 
> Also, will /sys/bus/ibmebus exist even if the system booted with no LHEA
> nodes?

Sure.
 
> Can we also have an attribute "devspec" that communicates the open
> firmware path through sysfs?

This is already taken care of by of_device_register().

Cheers,
  Joachim

---
Joachim Fenkes  --  eHCA Linux Driver Developer and Hardware Tamer 
extraordinaire
IBM Deutschland Entwicklung GmbH  --  Dept. 3627 (I/O Firmware Development 
2)
Schoenaicher Strasse 220  --  71032 Boeblingen  --  Germany
eMail: [EMAIL PROTECTED]  --  Phone: +49 7031 16 1239 

Vorsitzender des Aufsichtsrats: Johann Weihen  --  Geschäftsführung: 
Herbert Kircher
Sitz der Gesellschaft: Böblingen  --  Registergericht: Amtsgericht 
Stuttgart, HRB 243294


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Fix constant folding and poor optimization in byte swapping code

[Trent Piepho]

Constant folding does not work for the swabXX() byte swapping functions,
and the C versions optimize poorly.

Attempting to initialize a global variable to swab16(0x1234) or put
something like "case swab32(42):" in a switch statement will not compile.
It can work, swab.h just isn't doing it correctly.  This patch fixes
that.

Contrary to the comment in asm-i386/byteorder.h, gcc does not recognize
the "C" version of swab16 and turn it into efficient code.  gcc can do
this, just not with the current code.  The simple function:

u16 foo(u16 x) { return swab16(x); }

Would compile to:
movzwl  %ax, %eax
movl%eax, %edx
shrl$8, %eax
sall$8, %edx
orl %eax, %edx

With this patch, it will compile to:
rolw$8, %ax

I also attempted to document the maze different macros/inline functions
that are used to create the final product.Fix constant folding and poor optimization in byte swapping code
From: Trent Piepho <[EMAIL PROTECTED]>

Constant folding does not work for the swabXX() byte swapping functions,
and the C versions optimize poorly.

Attempting to initialize a global variable to swab16(0x1234) or put
something like "case swab32(42):" in a switch statement will not compile. 
It can work, swab.h just isn't doing it correctly.  This patch fixes
that.

Contrary to the comment in asm-i386/byteorder.h, gcc does not recognize
the "C" version of swab16 and turn it into efficient code.  gcc can do
this, just not with the current code.  The simple function:

u16 foo(u16 x) { return swab16(x); }

Would compile to:
movzwl  %ax, %eax
movl%eax, %edx
shrl$8, %eax
sall$8, %edx
orl %eax, %edx

With this patch, it will compile to:
rolw$8, %ax

I also attempted to document the maze different macros/inline functions
that are used to create the final product.

Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
CC: Francois-Rene Rideau <[EMAIL PROTECTED]>
---

 swab.h |  110 +
 1 files changed, 70 insertions(+), 40 deletions(-)

diff -r 2a44233ff44e -r dff6a3ea12f1 include/linux/byteorder/swab.h
--- a/include/linux/byteorder/swab.hTue Feb 13 22:02:32 2007 -0800
+++ b/include/linux/byteorder/swab.hFri Feb 16 15:53:06 2007 -0800
@@ -10,6 +10,10 @@
  *separated swab functions from cpu_to_XX,
  *to clean up support for bizarre-endian architectures.
  *
+ * Trent Piepho <[EMAIL PROTECTED]> 2007114
+ *make constant-folding work, provide C versions that
+ *gcc can optimize better, explain different versions
+ *
  * See asm-i386/byteorder.h and suches for examples of how to provide
  * architecture-dependent optimized versions
  *
@@ -17,40 +21,66 @@
 
 #include 
 
+/* Functions/macros defined, there are a lot:
+ * 
+ * ___swabXX
+ *Generic C versions of the swab functions.
+ *
+ * ___constant_swabXX
+ *C versions that gcc can fold into a compile-time constant when
+ *the argument is a compile-time constant.
+ * 
+ * __arch__swabXX[sp]?
+ *Architecture optimized versions of all the swab functions
+ *(including the s and p versions).  These can be defined in
+ *asm-arch/byteorder.h.  Any which are not, are defined here. 
+ *__arch__swabXXs() is defined in terms of __arch__swabXXp(), which
+ *is defined in terms of __arch__swabXX(), which is in turn defined
+ *in terms of ___swabXX(x).
+ *These must be macros.  They may be unsafe for arguments with 
+ *side-effects.
+ *
+ * __fswabXX
+ *Inline function versions of the __arch__ macros.  These _are_ safe 
+ *if the arguments have side-effects.  Note there are no s and p
+ *versions of these.
+ *
+ * __swabXX[sb]
+ *There are the ones you should actually use.  The __swabXX versions 
+ *will be a constant given a constant argument and use the arch
+ *specific code (if any) for non-constant arguments.  The s and p
+ *versions always use the arch specific code (constant folding
+ *doesn't apply).  They are safe to use with arguments with
+ *side-effects.
+ *
+ * swabXX[sb]
+ *Nicknames for __swabXX[sb] to use in the kernel.
+ */
+  
 /* casts are necessary for constants, because we never know how for sure
  * how U/UL/ULL map to __u16, __u32, __u64. At least not in a portable way.
  */
-#define ___swab16(x) \
-({ \
-   __u16 __x = (x); \
-   ((__u16)( \
-   (((__u16)(__x) & (__u16)0x00ffU) << 8) | \
-   (((__u16)(__x) & (__u16)0xff00U) >> 8) )); \
-})
-
-#define ___swab32(x) \
-({ \
-   __u32 __x = (x); \
-   ((__u32)( \
-   (((__u32)(__x) & (__u32)0x00ffUL) << 24) | \
-   (((__u32)(__x) & (__u32)0xff00UL) <<  8) | \
-   (((__u32)(__x) & (__u32)0x00ffUL) >>  8) | \
-   (((__u32)(__x) & (__u32)0xff00UL) >> 24) )); \
-})
-
-#define ___swab64(x) \
-({ \
-   __u64 __x = (x); \
-   ((__u64)( \
-  

Re: [PATCH] nfs: init req_lock in nfs_alloc_inode

[Andrew Morton]

On Fri, 16 Feb 2007 11:05:32 -0600
[EMAIL PROTECTED] (Olof Johansson) wrote:

> + nfsi->req_lock = SPIN_LOCK_UNLOCKED;

This can confound lockdep.  Please use spin_lock_init().
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG?] register_blkdev: failed to get major for device mapper

[Andrew Morton]

On Fri, 16 Feb 2007 14:37:28 +0100
Rolf Eike Beer <[EMAIL PROTECTED]> wrote:

> I can't bring up my machine with root LVM anymore using x86_64. The same 
> machine from same kernel tree boots fine as x86. The error message is quoted 
> in subject. The tree is at 86a71dbd3e81e8870d0f0e56b87875f57e58222b (for 
> those not using git: somewhere after 2.6.20).

Does this fix it?  I don't see why it would, but this was recently added.

--- a/block/genhd.c~a
+++ a/block/genhd.c
@@ -61,14 +61,6 @@ int register_blkdev(unsigned int major, 
/* temporary */
if (major == 0) {
for (index = ARRAY_SIZE(major_names)-1; index > 0; index--) {
-   /*
-* Disallow the LANANA-assigned LOCAL/EXPERIMENTAL
-* majors
-*/
-   if ((60 <= index && index <= 63) ||
-   (120 <= index && index <= 127) ||
-   (240 <= index && index <= 254))
-   continue;
if (major_names[index] == NULL)
break;
}
_

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [uml-devel] x86_64: fix 2.6.18 regression - PTRACE_OLDSETOPTIONS should be accepted

[Blaisorblade]

On Friday 16 February 2007 20:02, Jeff Dike wrote:
> On Thu, Feb 15, 2007 at 08:05:56PM +0100, Blaisorblade wrote:
> > Jeff, I verified my patch is _almost_ enough for 2.6.18 for fully booting
> > a 32bit UML; on 2.6.18 I had to also add PTRACE_GET/SET_THREAD_AREA (this
> > fix was merged in 2.6.19) to avoid tons of TLS errors.
>
> I'm not seeing that.  With the current set of patches, I have 32-bit UMLs
> happily booting on x86_64.
Which kernel? I've not yet tested 2.6.20. I'll try debugging this 
subsequently.
-- 
Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Kbuild problem (was: [2.6 patch] drivers/isdn/gigaset/: build asyncdata.o into the gigaset module)

[Tilman Schmidt]

Am 16.02.2007 09:33 schrieb Adrian Bunk:
>>> ...
>>>   LD  drivers/isdn/gigaset/built-in.o
>>> drivers/isdn/gigaset/ser_gigaset.o: In function `gigaset_m10x_send_skb':
>>> (.text+0xe50): multiple definition of `gigaset_m10x_send_skb'
>>> drivers/isdn/gigaset/usb_gigaset.o:(.text+0x0): first defined here
>>> drivers/isdn/gigaset/ser_gigaset.o: In function `gigaset_m10x_input':
>>> (.text+0x1121): multiple definition of `gigaset_m10x_input'
>>> drivers/isdn/gigaset/usb_gigaset.o:(.text+0x2d1): first defined here
>>> make[4]: *** [drivers/isdn/gigaset/built-in.o] Error 1

> CONFIG_ISDN_DRV_GIGASET=y
> CONFIG_GIGASET_BASE=y
> CONFIG_GIGASET_M105=y
> CONFIG_GIGASET_M101=y

Ah, thanks, I can see what's happening now. When both the M101 and M105
drivers are built into the kernel, asyncdata.o gets linked in twice, via

usb_gigaset-y := usb-gigaset.o asyncdata.o
obj-$(CONFIG_GIGASET_M105) += usb_gigaset.o gigaset.o

and

ser_gigaset-y := ser-gigaset.o asyncdata.o
obj-$(CONFIG_GIGASET_M101) += ser_gigaset.o gigaset.o

The assertion in Documentation/kbuild/makefiles.txt:

The order of files in $(obj-y) is significant.  Duplicates in
the lists are allowed: the first instance will be linked into
built-in.o and succeeding instances will be ignored.

doesn't work out in this case because asyncdata.o isn't added directly
to $(obj-y), but as part of usb_gigaset.o and ser_gigaset.o.

I'm not quite happy with your solution, though. I'd prefer a
Makefile which builds modular usb_gigaset.ko and/or ser_gigaset.ko
like the present one (including asyncdata.o), but when linking
usb-gigaset.o and ser-gigaset.o into the kernel includes asyncdata.o
only once. Trouble is, I don't know how to express that in Kbuild.

Any ideas?

Thanks,
Tilman

-- 
Tilman Schmidt  E-Mail: [EMAIL PROTECTED]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)



signature.asc
Description: OpenPGP digital signature

[PATCH] Remove obsolete raw device support.

[Robert P. J. Day]

  Remove the long-obsolete "raw device" support.

Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>

---

  based on this excerpt from
Documentation/feature-removal-schedule.txt:

What:   RAW driver (CONFIG_RAW_DRIVER)
When:   December 2005
Why:declared obsolete since kernel 2.6.3
O_DIRECT can be used instead
Who:Adrian Bunk <[EMAIL PROTECTED]>

all of this looks like it can be safely tossed.  compile-tested with
"make allyesconfig" on x86.

 Documentation/feature-removal-schedule.txt |8
 Documentation/ioctl-number.txt |1
 drivers/char/Kconfig   |   21 -
 drivers/char/Makefile  |1
 drivers/char/mem.c |1
 drivers/char/raw.c |  306 ---
 fs/compat_ioctl.c  |   71 
 include/linux/Kbuild   |1
 include/linux/compat_ioctl.h   |3
 include/linux/raw.h|   18 -
 10 files changed, 431 deletions(-)

diff --git a/Documentation/feature-removal-schedule.txt 
b/Documentation/feature-removal-schedule.txt
index c585aa8..29bdd4d 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -21,14 +21,6 @@ Who: Pavel Machek <[EMAIL PROTECTED]>

 ---

-What:  RAW driver (CONFIG_RAW_DRIVER)
-When:  December 2005
-Why:   declared obsolete since kernel 2.6.3
-   O_DIRECT can be used instead
-Who:   Adrian Bunk <[EMAIL PROTECTED]>
-

-
 What:  raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN
 When:  June 2007
 Why:   Deprecated in favour of the more efficient and robust rawiso interface.
diff --git a/Documentation/ioctl-number.txt b/Documentation/ioctl-number.txt
index 8f750c0..96a3b91 100644
--- a/Documentation/ioctl-number.txt
+++ b/Documentation/ioctl-number.txt
@@ -178,7 +178,6 @@ CodeSeq#Include FileComments

 0xA3   90-9F   linux/dtlk.h
 0xAB   00-1F   linux/nbd.h
-0xAC   00-1F   linux/raw.h
 0xAD   00  Netfilter devicein development:

 0xB0   all RATIO devices   in development:
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index d0a6dc5..560fbe8 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -955,27 +955,6 @@ config GPIO_VR41XX
tristate "NEC VR4100 series General-purpose I/O Unit support"
depends on CPU_VR41XX

-config RAW_DRIVER
-   tristate "RAW driver (/dev/raw/rawN) (OBSOLETE)"
-   depends on BLOCK
-   help
- The raw driver permits block devices to be bound to /dev/raw/rawN.
- Once bound, I/O against /dev/raw/rawN uses efficient zero-copy I/O.
- See the raw(8) manpage for more details.
-
-  The raw driver is deprecated and will be removed soon.
-  Applications should simply open the device (eg /dev/hda1)
-  with the O_DIRECT flag.
-
-config MAX_RAW_DEVS
-   int "Maximum number of RAW devices to support (1-8192)"
-   depends on RAW_DRIVER
-   default "256"
-   help
- The maximum number of RAW devices that are supported.
- Default is 256. Increase this number in case you need lots of
- raw devices.
-
 config HPET
bool "HPET - High Precision Event Timer" if (X86 || IA64)
default n
diff --git a/drivers/char/Makefile b/drivers/char/Makefile
index ae8567c..65df838 100644
--- a/drivers/char/Makefile
+++ b/drivers/char/Makefile
@@ -47,7 +47,6 @@ obj-$(CONFIG_HVC_ISERIES) += hvc_iseries.o
 obj-$(CONFIG_HVC_RTAS) += hvc_rtas.o
 obj-$(CONFIG_HVC_BEAT) += hvc_beat.o
 obj-$(CONFIG_HVC_DRIVER)   += hvc_console.o
-obj-$(CONFIG_RAW_DRIVER)   += raw.o
 obj-$(CONFIG_SGI_SNSC) += snsc.o snsc_event.o
 obj-$(CONFIG_MSPEC)+= mspec.o
 obj-$(CONFIG_MMTIMER)  += mmtimer.o
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index f5c160c..8df68d7 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/char/raw.c b/drivers/char/raw.c
deleted file mode 100644
index 1f0d7c6..000
--- a/drivers/char/raw.c
+++ /dev/null
@@ -1,306 +0,0 @@
-/*
- * linux/drivers/char/raw.c
- *
- * Front-end raw character devices.  These can be bound to any block
- * devices to provide genuine Unix raw character device semantics.
- *
- * We reserve minor number 0 for a control interface.  ioctl()s on this
- * device are used to bind the other minor numbers to block devices.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-struct raw_device_data {
-   struct block_device *binding;
-   int inuse;
-};
-

[kj][RFC] roll macro's in bitops.h

[Darren Jenkins\\]

G'day people,

I was looking at bitops.h and noticed there were a couple of inline roll
functions to operate on 32bit variables. (left and right)

I think that is a little bit dumb as they are constant width (only
32bits) due to it being an inline function, and was wondering if anyone
thought it would be useful to have some (variable sized) roll macros
instead.

I whipped these twp up as examples, but have not tested them yet.

#define RollRight(Data, Distance) \
({  typeof(Data) __a = Data;   \
typeof(Distance) __b = Distance%(sizeof(__a) * 8); \
__a = ((__a>>__b) | (__a<<((sizeof(__a) * 8) - __b))) \
__a; \
})

#define RollLeft(Data, Distance) \
({  typeof(Data) __a = Data;   \
typeof(Distance) __b = Distance%(sizeof(__a) * 8); \
__a = ((__a<<__b) | (__a>>((sizeof(__a) * 8) - __b))) \
__a; \
})

Also if these are useful I was wondering how to handle the existing
functions ? #define them out for the time being ?

#define rol32(a, b) RollLeft(a, b)
#define ror32(a, b) RollRight(a, b)




Darren Jenkins


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: MediaGX/GeodeGX1 requires X86_OOSTORE. (Was: Re: Strange connection slowdown on pcnet32)

[Lennart Sorensen]

On Fri, Feb 16, 2007 at 05:48:24PM -0500, Lennart Sorensen wrote:
> Well so far it really looks like enabling OOSTORE on the Geode
> SC1200/GX1 really does make a difference.  A bit of searching seems to
> indicate the person that originally submitted the patch that enabled
> load/store reordering on the MediaGX/Geode though it might need OOSTORE,
> but was convinced by others it didn't.  Looks like it really does need
> it.  The failure that occoured before within a few seconds of starting a
> large transfer, no longer fails and all I did was enable
> CONFIG_X86_OOSTORE, and recompile pcnet32.ko and load the new module on
> the running system.  Moving back to the pcnet32.ko built without OOSTORE
> enabled hits the failure again within seconds, until ifconfig eth1
> down/up reinitialized it's descriptor ring, after which it survices
> another bit of transfer and then fails again.

Well forcing load/store serialize on the CPU doesn't help, disalbing
memory bypass doesn't help.  Enabling the X86_OOSTORE does help.  What a
stupid CPU design.

So far nothing has managed to fix the __memcpy_toio in the jsm driver
getting data out of order when sending on an exar pci uart chip.  Only
calling memcpy with one byte at a time seems to work there.  Works fine
on every other cpu of course.  What else am I going to discover is wrong
with this CPU.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH(Experimental) 2/4] Revert changes to workqueue.c

[Oleg Nesterov]

On 02/16, Srivatsa Vaddagiri wrote:
>
> Note with the change proposed in refrigerator, we can avoid
> CPU_DEAD_KILL_THREADS and do all cleanup in CPU_DEAD itself.

In that case (all processes are frozen when workqueue_cpu_callback()
calls cleanup_workqueue_thread()) I agree, it is better to just use
kthread_stop/kthread_should_stop.

This also means that probably it won't be convenient to do this change
"by small steps" as I suggested before.

Oleg.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20-mm1

[J.A. Magallón]

On Thu, 15 Feb 2007 21:30:06 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:

> 
> Nope, can't reproduce (the bug, that is).
> 
> Actually, the oops you have there is the fourth one, so we might be seeing
> downstream effects of oops #1.  Can you please capture the first oops
> trace?  Increasing the log buffer size or using netconsole might help.

Well, forget it. Booting without the nVidia driver makes the oopses go away.
I looks like nvidia is doing something strange with the i2c interface.
D**d closed source drivers...

--
J.A. Magallon  \   Software is like sex:
 \ It's better when it's free
Mandriva Linux release 2007.1 (Cooker) for i586
Linux 2.6.19-jam07 (gcc 4.1.2 20070115 (prerelease) 
(4.1.2-0.20070115.1mdv2007.1)) #2 SMP PREEMPT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pata_amd dropping to PIO on resume

[Jeff Garzik]

Robert Hancock wrote:

Tobias Diedrich wrote:

Possibly a known issue:

After resume pata_amd drops from UDMA/33 to PIO on my system.
Reloading the module puts both attached optical drives (master and
slave) back to UDMA/33.

AFAICS "simplex DMA is claimed by other device, disabling DMA" seems
to be causing it to drop to PIO (but only after a suspend/resume
cycle, not on boot or module load).

Burning a DVD with 6x speed using PIO makes heavy use of burnproof
and makes the whole system quite sluggish. :)


Yes, the fact that it's going into simplex mode is the problem, it 
wasn't in simplex to start with. It looks like pata_amd does an 
ata_pci_clear_simplex only for certain chip models, maybe this model 
needs it as well?




Deleting the ata_pci_clear_simplex() call, then adding 
ATA_FLAG_IGN_SIMPLEX to the ata_port_info info[] array, is also worth 
trying.


Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 00/21] Xen-paravirt: Xen guest implementation for paravirt_ops interface

[Jeremy Fitzhardinge]

Christoph Lameter wrote:
> I am thoroughly confused. Maybe that is because I have not been following 
> this issue closely but it seems that you are using the paravirt interface 
> as an API for Xen code in the guest? I thought the idea of paravirt was to 
> have an API that is generic? This patchset seems to be mostly realizing 
> Xen specific functionality? How does the code here interact with KVM, 
> VMWare and other hypervisors?

There are two things in this patch series: generic kernel changes, and
the core bits of Xen itself.

The earlier part of the patch contains changes to the core kernel which
are needed for Xen, but are generally harmless to non-paravirt use, or
to being virtualized under other hypervisors.   In some cases these are
plain bugfixes (like dealing with absent vga hardware), or things which
have become parameterised (like the pgd alignment, or whether we share
the kernel pmd in PAE mode).

But there are also extensions to the paravirt_ops interface.  The
largest of these is adding the appropriate hooks for
non-shadowed-pagetable hypervisors.  While Xen is the only example of
this at the moment, its not a Xen-specific set of hooks.  It allows a
hypervisor backend to have detailed control over what actually gets put
into pagetables; in Xen's case this means we can convert the kernel's
pseudo-physical addresses into machine addresses, but you could imagine
a hypervisor maintaining some other structure in parallel with the
pagetable or something like that.  An analogy would be extending the IO
DMA interfaces to account for an IOMMU, even if only one hardware
platform actually has an IOMMU.

The latter part of the series is basically pure Xen-specifc stuff, which
is almost entirely restricted to Xen-specific parts of the tree.  This
code introduces a number of new Xen-specific interfaces, but they're
completely distinct from paravirt_ops.

J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] please pull infiniband.git

[Roland Dreier]

Linus, please pull from

master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus

This tree is also available from kernel.org mirrors at:

git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git 
for-linus

This adds IB multicast tracking, to allow userspace to use multicast
groups in a sane way, an ehca interrupt handling fixup, and a few
other minor things.  I don't think there is anything major left, so we
should be good for 2.6.21-rc1 after this pull.

Dotan Barak (1):
  IB/mthca: Allow the QP state transition RESET->RESET

Hoang-Nam Nguyen (4):
  IB/ehca: Rework irq handler
  IB/ehca: Fix race condition/locking issues in scaling code
  IB/ehca: Allow en/disabling scaling code via module parameter
  IB/ehca: Change query_port() to return LINK_UP instead UNKNOWN

Michael S. Tsirkin (1):
  IPoIB: CM error handling thinko fix

Roland Dreier (5):
  IB/mthca: Fix allocation of ICM chunks in coherent memory
  IPoIB: Only allow root to change between datagram and connected mode
  IB/core: Fix sparse warnings about shadowed declarations
  IB/ipath: Make ipath_map_sg() static
  IB/core: Set static rate in ib_init_ah_from_path()

Sean Hefty (2):
  IB/sa: Track multicast join/leave requests
  RDMA/cma: Add multicast communication support

Steve Wise (3):
  RDMA/iwcm: iw_cm_id destruction race fixes
  RDMA/cxgb3: Fail posts synchronously when in TERMINATE state
  RDMA/cxgb3: Remove Open Grid Computing copyrights in iw_cxgb3 driver

 drivers/infiniband/core/Makefile   |2 +-
 drivers/infiniband/core/cma.c  |  359 +--
 drivers/infiniband/core/fmr_pool.c |4 +-
 drivers/infiniband/core/iwcm.c |   47 +-
 drivers/infiniband/core/multicast.c|  837 
 drivers/infiniband/core/sa.h   |   66 ++
 drivers/infiniband/core/sa_query.c |   30 +-
 drivers/infiniband/core/sysfs.c|2 -
 drivers/infiniband/core/ucma.c |  204 ++-
 drivers/infiniband/hw/cxgb3/cxio_dbg.c |1 -
 drivers/infiniband/hw/cxgb3/cxio_hal.c |1 -
 drivers/infiniband/hw/cxgb3/cxio_hal.h |1 -
 drivers/infiniband/hw/cxgb3/cxio_resource.c|1 -
 drivers/infiniband/hw/cxgb3/cxio_resource.h|1 -
 drivers/infiniband/hw/cxgb3/cxio_wr.h  |1 -
 drivers/infiniband/hw/cxgb3/iwch.c |1 -
 drivers/infiniband/hw/cxgb3/iwch.h |1 -
 drivers/infiniband/hw/cxgb3/iwch_cm.c  |1 -
 drivers/infiniband/hw/cxgb3/iwch_cm.h  |1 -
 drivers/infiniband/hw/cxgb3/iwch_cq.c  |1 -
 drivers/infiniband/hw/cxgb3/iwch_ev.c  |1 -
 drivers/infiniband/hw/cxgb3/iwch_mem.c |1 -
 drivers/infiniband/hw/cxgb3/iwch_provider.c|1 -
 drivers/infiniband/hw/cxgb3/iwch_provider.h|1 -
 drivers/infiniband/hw/cxgb3/iwch_qp.c  |3 +-
 drivers/infiniband/hw/cxgb3/iwch_user.h|1 -
 drivers/infiniband/hw/ehca/Kconfig |8 -
 drivers/infiniband/hw/ehca/ehca_classes.h  |   19 +-
 drivers/infiniband/hw/ehca/ehca_eq.c   |1 +
 drivers/infiniband/hw/ehca/ehca_hca.c  |3 +
 drivers/infiniband/hw/ehca/ehca_irq.c  |  307 +
 drivers/infiniband/hw/ehca/ehca_irq.h  |1 +
 drivers/infiniband/hw/ehca/ehca_main.c |   32 +-
 drivers/infiniband/hw/ehca/ipz_pt_fn.h |   11 +-
 drivers/infiniband/hw/ipath/ipath_dma.c|4 +-
 drivers/infiniband/hw/mthca/mthca_memfree.c|4 +-
 drivers/infiniband/hw/mthca/mthca_qp.c |5 +
 drivers/infiniband/ulp/ipoib/ipoib_cm.c|4 +-
 drivers/infiniband/ulp/ipoib/ipoib_multicast.c |  195 ++
 include/rdma/ib_addr.h |6 +
 include/rdma/ib_sa.h   |  159 ++---
 include/rdma/rdma_cm.h |   21 +-
 include/rdma/rdma_cm_ib.h  |4 +-
 include/rdma/rdma_user_cm.h|   13 +-
 44 files changed, 1889 insertions(+), 478 deletions(-)
 create mode 100644 drivers/infiniband/core/multicast.c
 create mode 100644 drivers/infiniband/core/sa.h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] DualFS: File System with Meta-data and Data Separation

[Bill Davidsen]

Jörn Engel wrote:

On Thu, 15 February 2007 23:59:14 +0100, Juan Piernas Canovas wrote:
Actually, the version of DualFS for Linux 2.4.19 implements a cleaner. In 
our case, the cleaner is not really a problem because there is not too 
much to clean (the meta-data device only contains meta-data blocks which 
are 5-6% of the file system blocks; you do not have to move data blocks).


That sounds as if you have not hit the "interesting" cases yet.  Fun
starts when your device is near-full and you have a write-intensive
workload.  In your case, that would be metadata-write-intensive.  For
one, this is where write performance of log-structured filesystems
usually goes down the drain.  And worse, it is where the cleaner can
run into a deadlock.

Being good where log-structured filesystems usually are horrible is a
challenge.  And I'm sure many people are more interested in those
performance number than in the ones you shine at. :)

Actually I am interested in the common case, where the machine is not 
out of space, or memory, or CPU, but when it is appropriately sized to 
the workload. Not that I lack interest in corner cases, but the "running 
flat out" case doesn't reflect case where there's enough hardware, now 
the o/s needs to use it well.


The one high load benchmark I would love to see is a web server, running 
tux, with a load over a large (number of files) distributed data set. 
The much faster tar create times posted make me think that a server with 
a lot of files would benefit, when CPU and memory requirements are not a 
bottleneck.


--
Bill Davidsen <[EMAIL PROTECTED]>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas

[Jeremy Fitzhardinge]

Keir Fraser wrote:
> It has no other users right now and get_vm_area_sync() would be a
> better-named and more generically useful function than alloc_vm_area().
I'm thinking "reserve" might be a better term; "get" generally has the
suggestion of a refcount.

> get_vm_area_sync(), partnered with existing remove_vm_area(), just seems
> much smaller and neater than adding four new functions with a more complex
> usage: alloc_vm_area, {lock,unlock}_vm_area, and free_vm_area. Maybe keeping
> free_vm_area() too makes sense as its interface is more neatly symmetrical
> to that of get_vm_area().

I've already killed the lock/unlock functions.  I'll come up with
something for the get/allocate/reserve and free functions.

J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 09/10] pcmcia: some class_device fallout

[Greg Kroah-Hartman]

From: Alexey Dobriyan <[EMAIL PROTECTED]>

As found on some arm defconfigs.

I only looked at how original patch changes things and other patches fix
compilation. ;-)

Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
Cc: Dominik Brodowski <[EMAIL PROTECTED]>
Cc: Russell King <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 drivers/pcmcia/at91_cf.c|2 +-
 drivers/pcmcia/soc_common.c |8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/pcmcia/at91_cf.c b/drivers/pcmcia/at91_cf.c
index b318628..99baabc 100644
--- a/drivers/pcmcia/at91_cf.c
+++ b/drivers/pcmcia/at91_cf.c
@@ -277,7 +277,7 @@ static int __init at91_cf_probe(struct platform_device 
*pdev)
board->det_pin, board->irq_pin);
 
cf->socket.owner = THIS_MODULE;
-   cf->socket.dev.dev = >dev;
+   cf->socket.dev.parent = >dev;
cf->socket.ops = _cf_ops;
cf->socket.resource_ops = _static_ops;
cf->socket.features = SS_CAP_PCCARD | SS_CAP_STATIC_MAP
diff --git a/drivers/pcmcia/soc_common.c b/drivers/pcmcia/soc_common.c
index d2a3bea..aa7779d 100644
--- a/drivers/pcmcia/soc_common.c
+++ b/drivers/pcmcia/soc_common.c
@@ -478,7 +478,7 @@ dump_bits(char **p, const char *prefix, unsigned int val, 
struct bittbl *bits, i
  *
  * Returns: the number of characters added to the buffer
  */
-static ssize_t show_status(struct device *dev, char *buf)
+static ssize_t show_status(struct device *dev, struct device_attribute *attr, 
char *buf)
 {
struct soc_pcmcia_socket *skt =
container_of(dev, struct soc_pcmcia_socket, socket.dev);
@@ -501,7 +501,7 @@ static ssize_t show_status(struct device *dev, char *buf)
 
return p-buf;
 }
-static CLASS_DEVICE_ATTR(status, S_IRUGO, show_status, NULL);
+static DEVICE_ATTR(status, S_IRUGO, show_status, NULL);
 
 
 static struct pccard_operations soc_common_pcmcia_operations = {
@@ -660,7 +660,7 @@ int soc_common_drv_pcmcia_probe(struct device *dev, struct 
pcmcia_low_level *ops
 
skt->socket.ops = _common_pcmcia_operations;
skt->socket.owner = ops->owner;
-   skt->socket.dev.dev = dev;
+   skt->socket.dev.parent = dev;
 
init_timer(>poll_timer);
skt->poll_timer.function = soc_common_pcmcia_poll_event;
@@ -747,7 +747,7 @@ int soc_common_drv_pcmcia_probe(struct device *dev, struct 
pcmcia_low_level *ops
 
add_timer(>poll_timer);
 
-   device_create_file(>socket.dev, _attr_status);
+   device_create_file(>socket.dev, _attr_status);
}
 
dev_set_drvdata(dev, sinfo);
-- 
1.5.0

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 08/10] Driver core: device_add_attrs() cleanup

[Greg Kroah-Hartman]

From: Andrew Morton <[EMAIL PROTECTED]>

Clean up the coding in device_add_attrs() a bit.

Cc: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 drivers/base/bus.c |   22 ++
 1 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 472810f..253868e 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -324,27 +324,25 @@ int bus_for_each_drv(struct bus_type * bus, struct 
device_driver * start,
return error;
 }
 
-static int device_add_attrs(struct bus_type * bus, struct device * dev)
+static int device_add_attrs(struct bus_type *bus, struct device *dev)
 {
int error = 0;
int i;
 
-   if (bus->dev_attrs) {
-   for (i = 0; attr_name(bus->dev_attrs[i]); i++) {
-   error = device_create_file(dev,>dev_attrs[i]);
-   if (error)
-   goto Err;
+   if (!bus->dev_attrs)
+   return 0;
+
+   for (i = 0; attr_name(bus->dev_attrs[i]); i++) {
+   error = device_create_file(dev,>dev_attrs[i]);
+   if (error) {
+   while (--i >= 0)
+   device_remove_file(dev, >dev_attrs[i]);
+   break;
}
}
- Done:
return error;
- Err:
-   while (--i >= 0)
-   device_remove_file(dev,>dev_attrs[i]);
-   goto Done;
 }
 
-
 static void device_remove_attrs(struct bus_type * bus, struct device * dev)
 {
int i;
-- 
1.5.0

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 10/10] sysfs: fix build errors: uevent with CONFIG_SYSFS=n

[Greg Kroah-Hartman]

From: Randy Dunlap <[EMAIL PROTECTED]>

Fix source files to build with CONFIG_SYSFS=n.
module_subsys is not available.

SYSFS=n, MODULES=y: T:y
SYSFS=n, MODULES=n: T:y

SYSFS=y, MODULES=y: T:y
SYSFS=y, MODULES=n: T:y

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 include/linux/module.h  |   53 +++---
 include/linux/moduleparam.h |   12 +
 kernel/module.c |   14 ---
 kernel/params.c |   28 --
 4 files changed, 81 insertions(+), 26 deletions(-)

diff --git a/include/linux/module.h b/include/linux/module.h
index 419d3ef..95679eb 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -76,8 +76,6 @@ void sort_extable(struct exception_table_entry *start,
  struct exception_table_entry *finish);
 void sort_main_extable(void);
 
-extern struct subsystem module_subsys;
-
 #ifdef MODULE
 #define MODULE_GENERIC_TABLE(gtype,name)   \
 extern const struct gtype##_id __mod_##gtype##_table   \
@@ -467,10 +465,6 @@ int unregister_module_notifier(struct notifier_block * nb);
 
 extern void print_modules(void);
 
-struct device_driver;
-void module_add_driver(struct module *, struct device_driver *);
-void module_remove_driver(struct device_driver *);
-
 #else /* !CONFIG_MODULES... */
 #define EXPORT_SYMBOL(sym)
 #define EXPORT_SYMBOL_GPL(sym)
@@ -568,18 +562,59 @@ static inline void print_modules(void)
 {
 }
 
+#endif /* CONFIG_MODULES */
+
 struct device_driver;
+#ifdef CONFIG_SYSFS
 struct module;
 
-static inline void module_add_driver(struct module *module, struct 
device_driver *driver)
+extern struct subsystem module_subsys;
+
+int mod_sysfs_init(struct module *mod);
+int mod_sysfs_setup(struct module *mod,
+  struct kernel_param *kparam,
+  unsigned int num_params);
+int module_add_modinfo_attrs(struct module *mod);
+void module_remove_modinfo_attrs(struct module *mod);
+
+#else /* !CONFIG_SYSFS */
+
+static inline int mod_sysfs_init(struct module *mod)
 {
+   return 0;
 }
 
-static inline void module_remove_driver(struct device_driver *driver)
+static inline int mod_sysfs_setup(struct module *mod,
+  struct kernel_param *kparam,
+  unsigned int num_params)
 {
+   return 0;
 }
 
-#endif /* CONFIG_MODULES */
+static inline int module_add_modinfo_attrs(struct module *mod)
+{
+   return 0;
+}
+
+static inline void module_remove_modinfo_attrs(struct module *mod)
+{ }
+
+#endif /* CONFIG_SYSFS */
+
+#if defined(CONFIG_SYSFS) && defined(CONFIG_MODULES)
+
+void module_add_driver(struct module *mod, struct device_driver *drv);
+void module_remove_driver(struct device_driver *drv);
+
+#else /* not both CONFIG_SYSFS && CONFIG_MODULES */
+
+static inline void module_add_driver(struct module *mod, struct device_driver 
*drv)
+{ }
+
+static inline void module_remove_driver(struct device_driver *drv)
+{ }
+
+#endif
 
 #define symbol_request(x) try_then_request_module(symbol_get(x), "symbol:" #x)
 
diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index 4a189da..b26b2e5 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -169,10 +169,22 @@ extern int param_get_string(char *buffer, struct 
kernel_param *kp);
 
 struct module;
 
+#if defined(CONFIG_SYSFS) && defined(CONFIG_MODULES)
 extern int module_param_sysfs_setup(struct module *mod,
struct kernel_param *kparam,
unsigned int num_params);
 
 extern void module_param_sysfs_remove(struct module *mod);
+#else
+static inline int module_param_sysfs_setup(struct module *mod,
+struct kernel_param *kparam,
+unsigned int num_params)
+{
+   return 0;
+}
+
+static inline void module_param_sysfs_remove(struct module *mod)
+{ }
+#endif
 
 #endif /* _LINUX_MODULE_PARAMS_H */
diff --git a/kernel/module.c b/kernel/module.c
index e06b77a..8c25b1a 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1074,7 +1074,8 @@ static inline void remove_sect_attrs(struct module *mod)
 }
 #endif /* CONFIG_KALLSYMS */
 
-static int module_add_modinfo_attrs(struct module *mod)
+#ifdef CONFIG_SYSFS
+int module_add_modinfo_attrs(struct module *mod)
 {
struct module_attribute *attr;
struct module_attribute *temp_attr;
@@ -1100,7 +1101,7 @@ static int module_add_modinfo_attrs(struct module *mod)
return error;
 }
 
-static void module_remove_modinfo_attrs(struct module *mod)
+void module_remove_modinfo_attrs(struct module *mod)
 {
struct module_attribute *attr;
int i;
@@ -1115,8 +1116,10 @@ static void module_remove_modinfo_attrs(struct module 
*mod)
}
kfree(mod->modinfo_attrs);
 }
+#endif
 
-static int mod_sysfs_init(struct module *mod)
+#ifdef 

[PATCH 07/10] debugfs: Remove misleading comments.

[Greg Kroah-Hartman]

From: Cornelia Huck <[EMAIL PROTECTED]>

Just mention which error will be returned if debugfs is disabled. Callers
should be able to figure out themselves what they need to check.

Signed-off-by: Cornelia Huck <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 fs/debugfs/inode.c |   12 +++-
 1 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index 9c51a9f..7b324cf 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -212,9 +212,7 @@ static int debugfs_create_by_name(const char *name, mode_t 
mode,
  * you are responsible here.)  If an error occurs, %NULL will be returned.
  *
  * If debugfs is not enabled in the kernel, the value -%ENODEV will be
- * returned.  It is not wise to check for this value, but rather, check for
- * %NULL or !%NULL instead as to eliminate the need for #ifdef in the calling
- * code.
+ * returned.
  */
 struct dentry *debugfs_create_file(const char *name, mode_t mode,
   struct dentry *parent, void *data,
@@ -264,9 +262,7 @@ EXPORT_SYMBOL_GPL(debugfs_create_file);
  * you are responsible here.)  If an error occurs, %NULL will be returned.
  *
  * If debugfs is not enabled in the kernel, the value -%ENODEV will be
- * returned.  It is not wise to check for this value, but rather, check for
- * %NULL or !%NULL instead as to eliminate the need for #ifdef in the calling
- * code.
+ * returned.
  */
 struct dentry *debugfs_create_dir(const char *name, struct dentry *parent)
 {
@@ -297,9 +293,7 @@ EXPORT_SYMBOL_GPL(debugfs_create_dir);
  * returned.
  *
  * If debugfs is not enabled in the kernel, the value -%ENODEV will be
- * returned.  It is not wise to check for this value, but rather, check for
- * %NULL or !%NULL instead as to eliminate the need for #ifdef in the calling
- * code.
+ * returned.
  */
 struct dentry *debugfs_create_symlink(const char *name, struct dentry *parent,
  const char *target)
-- 
1.5.0

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 05/10] Driver: remove redundant kobject_unregister checks

[Greg Kroah-Hartman]

From: Mariusz Kozlowski <[EMAIL PROTECTED]>

Here is a patch that removes all redundant kobject_unregister argument checks.

Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 drivers/base/class.c  |3 +--
 fs/partitions/check.c |9 +++--
 kernel/module.c   |7 ++-
 3 files changed, 6 insertions(+), 13 deletions(-)

diff --git a/drivers/base/class.c b/drivers/base/class.c
index 96def1d..1417e5c 100644
--- a/drivers/base/class.c
+++ b/drivers/base/class.c
@@ -163,8 +163,7 @@ int class_register(struct class * cls)
 void class_unregister(struct class * cls)
 {
pr_debug("device class '%s': unregistering\n", cls->name);
-   if (cls->virtual_dir)
-   kobject_unregister(cls->virtual_dir);
+   kobject_unregister(cls->virtual_dir);
remove_class_attrs(cls);
subsystem_unregister(>subsys);
 }
diff --git a/fs/partitions/check.c b/fs/partitions/check.c
index ac32a2e..22d38ff 100644
--- a/fs/partitions/check.c
+++ b/fs/partitions/check.c
@@ -358,8 +358,7 @@ void delete_partition(struct gendisk *disk, int part)
p->ios[0] = p->ios[1] = 0;
p->sectors[0] = p->sectors[1] = 0;
sysfs_remove_link(>kobj, "subsystem");
-   if (p->holder_dir)
-   kobject_unregister(p->holder_dir);
+   kobject_unregister(p->holder_dir);
kobject_uevent(>kobj, KOBJ_REMOVE);
kobject_del(>kobj);
kobject_put(>kobj);
@@ -603,10 +602,8 @@ void del_gendisk(struct gendisk *disk)
disk->stamp = 0;
 
kobject_uevent(>kobj, KOBJ_REMOVE);
-   if (disk->holder_dir)
-   kobject_unregister(disk->holder_dir);
-   if (disk->slave_dir)
-   kobject_unregister(disk->slave_dir);
+   kobject_unregister(disk->holder_dir);
+   kobject_unregister(disk->slave_dir);
if (disk->driverfs_dev) {
char *disk_name = make_block_name(disk);
sysfs_remove_link(>kobj, "device");
diff --git a/kernel/module.c b/kernel/module.c
index 225501f..e06b77a 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1180,11 +1180,8 @@ static void mod_kobject_remove(struct module *mod)
 {
module_remove_modinfo_attrs(mod);
module_param_sysfs_remove(mod);
-   if (mod->mkobj.drivers_dir)
-   kobject_unregister(mod->mkobj.drivers_dir);
-   if (mod->holders_dir)
-   kobject_unregister(mod->holders_dir);
-
+   kobject_unregister(mod->mkobj.drivers_dir);
+   kobject_unregister(mod->holders_dir);
kobject_unregister(>mkobj.kobj);
 }
 
-- 
1.5.0

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 06/10] debugfs: implement symbolic links

[Greg Kroah-Hartman]

From: Peter Oberparleiter <[EMAIL PROTECTED]>

debugfs: implement symbolic links

Implement a new function debugfs_create_symlink() which can be used
to create symbolic links in debugfs. This function can be useful
for people moving functionality from /proc to debugfs (e.g. the
gcov-kernel patch).

Signed-off-by: Peter Oberparleiter <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 fs/debugfs/file.c   |   12 +++
 fs/debugfs/inode.c  |   76 --
 include/linux/debugfs.h |   10 ++
 3 files changed, 94 insertions(+), 4 deletions(-)

diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index 8d130cc..682f928 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static ssize_t default_read_file(struct file *file, char __user *buf,
@@ -44,6 +45,17 @@ const struct file_operations debugfs_file_operations = {
.open = default_open,
 };
 
+static void *debugfs_follow_link(struct dentry *dentry, struct nameidata *nd)
+{
+   nd_set_link(nd, dentry->d_inode->i_private);
+   return NULL;
+}
+
+const struct inode_operations debugfs_link_operations = {
+   .readlink   = generic_readlink,
+   .follow_link= debugfs_follow_link,
+};
+
 static void debugfs_u8_set(void *data, u64 val)
 {
*(u8 *)data = val;
diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index c692487..9c51a9f 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -25,11 +25,13 @@
 #include 
 #include 
 #include 
+#include 
 
 #define DEBUGFS_MAGIC  0x64626720
 
 /* declared over in file.c */
 extern struct file_operations debugfs_file_operations;
+extern struct inode_operations debugfs_link_operations;
 
 static struct vfsmount *debugfs_mount;
 static int debugfs_mount_count;
@@ -51,6 +53,9 @@ static struct inode *debugfs_get_inode(struct super_block 
*sb, int mode, dev_t d
case S_IFREG:
inode->i_fop = _file_operations;
break;
+   case S_IFLNK:
+   inode->i_op = _link_operations;
+   break;
case S_IFDIR:
inode->i_op = _dir_inode_operations;
inode->i_fop = _dir_operations;
@@ -96,6 +101,12 @@ static int debugfs_mkdir(struct inode *dir, struct dentry 
*dentry, int mode)
return res;
 }
 
+static int debugfs_link(struct inode *dir, struct dentry *dentry, int mode)
+{
+   mode = (mode & S_IALLUGO) | S_IFLNK;
+   return debugfs_mknod(dir, dentry, mode, 0);
+}
+
 static int debugfs_create(struct inode *dir, struct dentry *dentry, int mode)
 {
int res;
@@ -158,10 +169,17 @@ static int debugfs_create_by_name(const char *name, 
mode_t mode,
mutex_lock(>d_inode->i_mutex);
*dentry = lookup_one_len(name, parent, strlen(name));
if (!IS_ERR(*dentry)) {
-   if ((mode & S_IFMT) == S_IFDIR)
+   switch (mode & S_IFMT) {
+   case S_IFDIR:
error = debugfs_mkdir(parent->d_inode, *dentry, mode);
-   else 
+   break;
+   case S_IFLNK:
+   error = debugfs_link(parent->d_inode, *dentry, mode);
+   break;
+   default:
error = debugfs_create(parent->d_inode, *dentry, mode);
+   break;
+   }
dput(*dentry);
} else
error = PTR_ERR(*dentry);
@@ -259,6 +277,49 @@ struct dentry *debugfs_create_dir(const char *name, struct 
dentry *parent)
 EXPORT_SYMBOL_GPL(debugfs_create_dir);
 
 /**
+ * debugfs_create_symlink- create a symbolic link in the debugfs filesystem
+ * @name: a pointer to a string containing the name of the symbolic link to
+ *create.
+ * @parent: a pointer to the parent dentry for this symbolic link.  This
+ *  should be a directory dentry if set.  If this paramater is NULL,
+ *  then the symbolic link will be created in the root of the debugfs
+ *  filesystem.
+ * @target: a pointer to a string containing the path to the target of the
+ *  symbolic link.
+ *
+ * This function creates a symbolic link with the given name in debugfs that
+ * links to the given target path.
+ *
+ * This function will return a pointer to a dentry if it succeeds.  This
+ * pointer must be passed to the debugfs_remove() function when the symbolic
+ * link is to be removed (no automatic cleanup happens if your module is
+ * unloaded, you are responsible here.)  If an error occurs, %NULL will be
+ * returned.
+ *
+ * If debugfs is not enabled in the kernel, the value -%ENODEV will be
+ * returned.  It is not wise to check for this value, but rather, check for
+ * %NULL or !%NULL instead as to eliminate the need for #ifdef in the calling
+ * code.
+ */
+struct dentry 

[PATCH 04/10] kobject: kobj->k_name verification fix

[Greg Kroah-Hartman]

From: Martin Stoilov <[EMAIL PROTECTED]>

The function 'kobject_add' tries to verify the name of
a new kobject instance is properly set before continuing.
if (!kobj->k_name)
kobj->k_name = kobj->name;
if (!kobj->k_name) {
pr_debug("kobject attempted to be registered with no name!\n");
WARN_ON(1);
return -EINVAL;
}
The statement:
if (!kobj->k_name) {
pr_debug("kobject attempted to be registered with no name!\n");
WARN_ON(1);
return -EINVAL;
}
is useless the way it is right now, because it can never be true. I
think the
code was intended to be:
if (!kobj->k_name)
kobj->k_name = kobj->name;
if (!*kobj->k_name) {
pr_debug("kobject attempted to be registered with no name!\n");
WARN_ON(1);
return -EINVAL;
}
because this would make sure the kobj->name buffer has something in it.
So the missing '*' is just a typo. Although, I would much prefer
expression like:
if (*kobj->k_name == '\0') {
pr_debug("kobject attempted to be registered with no name!\n");
WARN_ON(1);
return -EINVAL;
}

because this would've made the intention clear, in this patch I just restore
the missing '*' without changing the coding style of the function.

Signed-off-by: Martin Stoilov <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 lib/kobject.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lib/kobject.c b/lib/kobject.c
index 2782f49..93685f4 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -171,7 +171,7 @@ int kobject_shadow_add(struct kobject * kobj, struct dentry 
*shadow_parent)
return -ENOENT;
if (!kobj->k_name)
kobj->k_name = kobj->name;
-   if (!kobj->k_name) {
+   if (!*kobj->k_name) {
pr_debug("kobject attempted to be registered with no name!\n");
WARN_ON(1);
return -EINVAL;
-- 
1.5.0

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 03/10] serial: Add PCMCIA IDs for Quatech DSP-100 dual RS232 adapter.

[Greg Kroah-Hartman]

From: Sergei Organov <[EMAIL PROTECTED]>

Add PCMCIA IDs for Quatech DSP-100 dual RS232 adapter.

Signed-off-by: Sergei Organov <[EMAIL PROTECTED]>
Acked-by: Alan Cox <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 drivers/serial/serial_cs.c |5 +
 include/pcmcia/ciscode.h   |1 +
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/serial/serial_cs.c b/drivers/serial/serial_cs.c
index c2f1012..6b76bab 100644
--- a/drivers/serial/serial_cs.c
+++ b/drivers/serial/serial_cs.c
@@ -248,6 +248,10 @@ static const struct serial_quirk quirks[] = {
.multi  = 2,
}, {
.manfid = MANFID_QUATECH,
+   .prodid = PRODID_QUATECH_DUAL_RS232_G,
+   .multi  = 2,
+   }, {
+   .manfid = MANFID_QUATECH,
.prodid = PRODID_QUATECH_QUAD_RS232,
.multi  = 4,
}, {
@@ -891,6 +895,7 @@ static struct pcmcia_device_id serial_ids[] = {
PCMCIA_DEVICE_PROD_ID12("OEM  ", "C288MX ", 0xb572d360, 
0xd2385b7a),
PCMCIA_DEVICE_PROD_ID12("PCMCIA   ", "C336MX ", 0x99bcafe9, 
0xaa25bcab),
PCMCIA_DEVICE_PROD_ID12("Quatech Inc", "PCMCIA Dual RS-232 Serial Port 
Card", 0xc4420b35, 0x92abc92f),
+   PCMCIA_DEVICE_PROD_ID12("Quatech Inc", "Dual RS-232 Serial Port PC 
Card", 0xc4420b35, 0x031a380d),
PCMCIA_PFC_DEVICE_CIS_PROD_ID12(1, "PCMCIA", "EN2218-LAN/MODEM", 
0x281f1c5d, 0x570f348e, "PCMLM28.cis"),
PCMCIA_PFC_DEVICE_CIS_PROD_ID12(1, "PCMCIA", "UE2218-LAN/MODEM", 
0x281f1c5d, 0x6fdcacee, "PCMLM28.cis"),
PCMCIA_PFC_DEVICE_CIS_PROD_ID12(1, "Psion Dacom", "Gold Card V34 
Ethernet", 0xf5f025c2, 0x338e8155, "PCMLM28.cis"),
diff --git a/include/pcmcia/ciscode.h b/include/pcmcia/ciscode.h
index c1da855..eae7e2e 100644
--- a/include/pcmcia/ciscode.h
+++ b/include/pcmcia/ciscode.h
@@ -95,6 +95,7 @@
 #define PRODID_QUATECH_DUAL_RS232  0x0012
 #define PRODID_QUATECH_DUAL_RS232_D1   0x0007
 #define PRODID_QUATECH_DUAL_RS232_D2   0x0052
+#define PRODID_QUATECH_DUAL_RS232_G0x004d
 #define PRODID_QUATECH_QUAD_RS232  0x001b
 #define PRODID_QUATECH_DUAL_RS422  0x000e
 #define PRODID_QUATECH_QUAD_RS422  0x0045
-- 
1.5.0

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 01/10] Driver.h copyright update

[Greg Kroah-Hartman]

It was pointed out that I had not updated my copyright on driver.h

Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 include/linux/device.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/linux/device.h b/include/linux/device.h
index 26e4692..d5b1b7b 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -2,6 +2,7 @@
  * device.h - generic, centralized driver model
  *
  * Copyright (c) 2001-2003 Patrick Mochel <[EMAIL PROTECTED]>
+ * Copyright (c) 2004-2007 Greg Kroah-Hartman <[EMAIL PROTECTED]>
  *
  * This file is released under the GPLv2
  *
-- 
1.5.0

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 02/10] Driver core: let request_module() send a /sys/modules/kmod/-uevent

[Greg Kroah-Hartman]

From: Kay Sievers <[EMAIL PROTECTED]>

On recent systems, calls to /sbin/modprobe are handled by udev depending
on the kind of device the kernel has discovered. This patch creates an
uevent for the kernels internal request_module(), to let udev take control
over the request, instead of forking the binary directly by the kernel.
The direct execution of /sbin/modprobe can be disabled by setting:
  /sys/module/kmod/mod_request_helper (/proc/sys/kernel/modprobe)
to an empty string, the same way /proc/sys/kernel/hotplug is disabled on an
udev system.

Signed-off-by: Kay Sievers <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 include/linux/kmod.h |2 +
 kernel/kmod.c|  120 ++
 kernel/module.c  |   26 +++
 kernel/params.c  |1 +
 4 files changed, 139 insertions(+), 10 deletions(-)

diff --git a/include/linux/kmod.h b/include/linux/kmod.h
index 10f505c..cc8e674 100644
--- a/include/linux/kmod.h
+++ b/include/linux/kmod.h
@@ -28,8 +28,10 @@
 #ifdef CONFIG_KMOD
 /* modprobe exit status on success, -ve on error.  Return value
  * usually useless though. */
+extern void kmod_sysfs_init(void);
 extern int request_module(const char * name, ...) __attribute__ ((format 
(printf, 1, 2)));
 #else
+static inline void kmod_sysfs_init(void) {};
 static inline int request_module(const char * name, ...) { return -ENOSYS; }
 #endif
 
diff --git a/kernel/kmod.c b/kernel/kmod.c
index 7962761..9f923f8 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -36,6 +36,8 @@
 #include 
 #include 
 
+extern int delete_module(const char *name, unsigned int flags);
+
 extern int max_threads;
 
 static struct workqueue_struct *khelper_wq;
@@ -46,6 +48,7 @@ static struct workqueue_struct *khelper_wq;
modprobe_path is set via /proc/sys.
 */
 char modprobe_path[KMOD_PATH_LEN] = "/sbin/modprobe";
+struct module_kobject kmod_mk;
 
 /**
  * request_module - try to load a kernel module
@@ -75,6 +78,11 @@ int request_module(const char *fmt, ...)
static atomic_t kmod_concurrent = ATOMIC_INIT(0);
 #define MAX_KMOD_CONCURRENT 50 /* Completely arbitrary value - KAO */
static int kmod_loop_msg;
+   char modalias[16 + MODULE_NAME_LEN] = "MODALIAS=";
+   char *uevent_envp[2] = {
+   modalias,
+   NULL
+   };
 
va_start(args, fmt);
ret = vsnprintf(module_name, MODULE_NAME_LEN, fmt, args);
@@ -82,6 +90,12 @@ int request_module(const char *fmt, ...)
if (ret >= MODULE_NAME_LEN)
return -ENAMETOOLONG;
 
+   strcpy([strlen("MODALIAS=")], module_name);
+   kobject_uevent_env(_mk.kobj, KOBJ_CHANGE, uevent_envp);
+
+   if (modprobe_path[0] == '\0')
+   goto out;
+
/* If modprobe needs a service that is in a module, we get a recursive
 * loop.  Limit the number of running kmod threads to max_threads/2 or
 * MAX_KMOD_CONCURRENT, whichever is the smaller.  A cleaner method
@@ -108,9 +122,115 @@ int request_module(const char *fmt, ...)
 
ret = call_usermodehelper(modprobe_path, argv, envp, 1);
atomic_dec(_concurrent);
+out:
return ret;
 }
 EXPORT_SYMBOL(request_module);
+
+static ssize_t store_mod_request(struct module_attribute *mattr,
+struct module *mod,
+ const char *buffer, size_t count)
+{
+   char name[MODULE_NAME_LEN];
+   int ret;
+
+   if (count < 1 || count+1 > MODULE_NAME_LEN)
+   return -EINVAL;
+   memcpy(name, buffer, count);
+   name[count] = '\0';
+   if (name[count-1] == '\n')
+   name[count-1] = '\0';
+
+   ret = request_module(name);
+   if (ret < 0)
+   return ret;
+   return count;
+}
+
+static struct module_attribute mod_request = {
+   .attr = { .name = "mod_request", .mode = S_IWUSR, .owner = THIS_MODULE 
},
+   .store = store_mod_request,
+};
+
+#ifdef CONFIG_MODULE_UNLOAD
+static ssize_t store_mod_unload(struct module_attribute *mattr,
+   struct module *mod,
+   const char *buffer, size_t count)
+{
+   char name[MODULE_NAME_LEN];
+   int ret;
+
+   if (count < 1 || count+1 > MODULE_NAME_LEN)
+   return -EINVAL;
+   memcpy(name, buffer, count);
+   name[count] = '\0';
+   if (name[count-1] == '\n')
+   name[count-1] = '\0';
+
+   ret = delete_module(name, O_NONBLOCK);
+   if (ret < 0)
+   return ret;
+   return count;
+}
+
+static struct module_attribute mod_unload = {
+   .attr = { .name = "mod_unload", .mode = S_IWUSR, .owner = THIS_MODULE },
+   .store = store_mod_unload,
+};
+#endif
+
+static ssize_t show_mod_request_helper(struct module_attribute *mattr,
+  struct module *mod,
+  char *buffer)
+{
+   return sprintf(buffer, 

Re: [PATCH 05/05] Linux Kernel Markers, non optimized architectures

[Mathieu Desnoyers]

* Karim Yaghmour ([EMAIL PROTECTED]) wrote:
> - KRYPTIVA PACKAGED MESSAGE -
> PACKAGING TYPE: SIGNED
> 
> Mathieu Desnoyers wrote:
> > The main goal of this config option is for embedded systems which doesn't 
> support live code modification. Maybe we can put that under "embedded 
> sytems" menu ?
> 
> Not sure whether you had had other feedback on this elsewhere in
> the rest of the thread, but yes, this would make sense if the
> "embedded" angle is the only reason we need this (and not, say,
> performance, etc.) Also, having done that, maybe it would make
> some sense to have it be a "disable" rather than "enable":
> CONFIG_MARKERS_DISABLE_OPTIMIZATION?
> 

Hi Karim,

Yes, that was indeed the first way I implemented it, as a "disable"
option. One of the main thing we have to figure out before I modify this
is if we want to have the generic version of markers available in a
"forced" manner at the marker site with the GEN_MARK macro instead of
the MARK macro (this is the actual implementation). It has proven to
be useful to instrument lockdep.c irq enable/disable tracing functions.
The reason why is because they are called just before the trap handler
returns and I need it to do XMC on x86 and x86_64. It would therefore
cause a recursive trap.

I think it makes sense to have this kind of support for hard-to-instrument
sites within the marker infrastructure, but the cost is to have two
marker flavors : MARK and GEN_MARK (but really GEN_MARK is only intended
for a few sites).

Mathieu

> Karim
> 
> 
> - KRYPTIVA SIGNED MESSAGE -
> This email claims to have been packaged by Kryptiva.
> To process this email and authenticate its origin, get
> the free plugin from:
> http://www.kryptiva.com/downloads
> 
> - KRYPTIVA SIGNATURE START -
> AvWVqAIBTiACAQC3AQAIAgECABTXxT4xHdR4/1uU1hL2
> +TaPrqNB0wMAFNa8GHXZWJH5Dz+D76vfh6JhvWLvBAAUpuIZcCAkCC+ldyaBuoAWxK50HiQF
> ABRI38gc/foDHQsS6X3W0VP4xTukBwYAFDzvzh+u6zVtolglAZrnE7FOmtZDBwAUTxyTas6N
> WLapdnSnAwVHeC06/ioRABgAAABOIEXWD8AACTdnAN8TAAQAggP+
> K8Gk1SWj+c67jiJerodkr1gntoa9dJVVN6InxB824CfKC6flE4JMWtffw0Dxh0cJ8iOQ8UeC
> zoWzTs9Z+K9j1CL11CHkIIit3RK3hnfnby6whr4xoZ9UX/BUUv8FVKZeyRg7SbDKlhEZTwIH
> 7axjVQJ6MGU7h+0/5dKCDMEtzPY=
> - KRYPTIVA SIGNATURE END -

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Candidate, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] usbnet/rndis (was: Is this bug too obvious?)

[David Brownell]

> If you don't do it sooner, I'll look at the error paths in rndis
> and/or usbnet.

Try that patch I sent by this morning.  ISTR getting some
positive reports from that...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PATCH] more PCI patches for 2.6.20

[Greg KH]

Here are some more PCI patches against 2.6.20-git

They are a few additional quirks, a new sysfs file for NUMA machines,
and some documentation fixes.

All of these have been in the -mm tree for a while.

Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6.git/

The full patches will be sent to the linux-pci mailing list, if anyone
wants to see it

thanks,

greg k-h

 Documentation/kernel-parameters.txt |6 ++
 Documentation/pci.txt   |4 +-
 arch/i386/pci/common.c  |   88 +++
 drivers/pci/pci-driver.c|1 +
 drivers/pci/pci-sysfs.c |   11 
 drivers/pci/pci.c   |   12 -
 drivers/pci/setup-bus.c |   27 ---
 drivers/pci/setup-irq.c |   18 ---
 fs/sysfs/file.c |2 +-
 include/linux/pci.h |3 +
 lib/kobject.c   |1 +
 11 files changed, 144 insertions(+), 29 deletions(-)

---

Andreas Block (1):
  PCI: PCI devices get assigned redundant IRQs

Andy Gospodarek (1):
  PCI: add systems for automatic breadth-first device sorting

Atsushi Nemoto (1):
  PCI: Make CARDBUS_MEM_SIZE and CARDBUS_IO_SIZE boot options

Brice Goglin (1):
  PCI: Make PCI device numa-node attribute visible in sysfs

Grant Grundler (1):
  PCI: pci.txt fix __devexit() usage

Randy Dunlap (1):
  PCI/sysfs/kobject kernel-doc fixes

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PATCH] more Driver core patches for 2.6.20

[Greg KH]

Here are some more driver core and debugfs patches and a serial port
device id addition for 2.6.20-git.

All of these have been in the -mm tree.

Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/

Patches will be sent as a follow-on to this message to lkml for people
to see.

thanks,

greg k-h

 drivers/base/bus.c  |   22 
 drivers/base/class.c|3 +-
 drivers/pcmcia/at91_cf.c|2 +-
 drivers/pcmcia/soc_common.c |8 ++--
 drivers/serial/serial_cs.c  |5 ++
 fs/debugfs/file.c   |   12 
 fs/debugfs/inode.c  |   82 ++
 fs/partitions/check.c   |9 +--
 include/linux/debugfs.h |   10 
 include/linux/device.h  |1 +
 include/linux/kmod.h|2 +
 include/linux/module.h  |   53 ---
 include/linux/moduleparam.h |   12 
 include/pcmcia/ciscode.h|1 +
 kernel/kmod.c   |  120 +++
 kernel/module.c |   47 ++---
 kernel/params.c |   29 ++-
 lib/kobject.c   |2 +-
 18 files changed, 343 insertions(+), 77 deletions(-)

---

Alexey Dobriyan (1):
  pcmcia: some class_device fallout

Andrew Morton (1):
  Driver core: device_add_attrs() cleanup

Cornelia Huck (1):
  debugfs: Remove misleading comments.

Greg Kroah-Hartman (1):
  Driver.h copyright update

Kay Sievers (1):
  Driver core: let request_module() send a /sys/modules/kmod/-uevent

Mariusz Kozlowski (1):
  Driver: remove redundant kobject_unregister checks

Martin Stoilov (1):
  kobject: kobj->k_name verification fix

Peter Oberparleiter (1):
  debugfs: implement symbolic links

Randy Dunlap (1):
  sysfs: fix build errors: uevent with CONFIG_SYSFS=n

Sergei Organov (1):
  serial: Add PCMCIA IDs for Quatech DSP-100 dual RS232 adapter.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PATCH] more USB patches for 2.6.20

[Greg KH]

Here are some more USB patches against 2.6.20-git

There's a tiny driver to charge blackberry devices, and lots of device
ids and bugfixes.

All of these have been in the -mm releases for a while.

Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/gregkh/usb-2.6.git/

The full patches will be sent to the linux-usb-devel mailing list, if
anyone wants to see them.

thanks,

greg k-h

 drivers/scsi/sd.c  |   11 +++-
 drivers/usb/Makefile   |1 +
 drivers/usb/atm/ueagle-atm.c   |1 +
 drivers/usb/class/cdc-acm.c|   33 ++---
 drivers/usb/core/devices.c |9 ++-
 drivers/usb/core/devio.c   |4 +-
 drivers/usb/core/driver.c  |1 +
 drivers/usb/core/endpoint.c|2 +-
 drivers/usb/core/generic.c |2 +-
 drivers/usb/core/hub.c |   31 
 drivers/usb/core/message.c |   22 +-
 drivers/usb/core/otg_whitelist.h   |2 +-
 drivers/usb/core/sysfs.c   |2 +-
 drivers/usb/gadget/at91_udc.c  |   15 ++--
 drivers/usb/gadget/serial.c|1 +
 drivers/usb/host/ehci-hcd.c|   36 --
 drivers/usb/host/ehci-hub.c|2 +
 drivers/usb/host/isp116x-hcd.c |2 +-
 drivers/usb/host/ohci-at91.c   |   50 +-
 drivers/usb/host/ohci-hcd.c|   18 --
 drivers/usb/input/hid-core.c   |8 +--
 drivers/usb/misc/Kconfig   |   11 +++
 drivers/usb/misc/Makefile  |1 +
 drivers/usb/misc/berry_charge.c|  140 
 drivers/usb/net/Kconfig|   11 +++-
 drivers/usb/net/asix.c |2 +
 drivers/usb/net/cdc_subset.c   |   21 +-
 drivers/usb/net/usbnet.c   |   29 
 drivers/usb/serial/airprime.c  |   35 ++---
 drivers/usb/serial/cp2101.c|1 +
 drivers/usb/serial/generic.c   |  102 +-
 drivers/usb/serial/option.c|4 -
 drivers/usb/serial/pl2303.c|1 +
 drivers/usb/serial/pl2303.h|5 ++
 drivers/usb/storage/scsiglue.c |6 ++
 drivers/usb/storage/unusual_devs.h |   26 ++-
 drivers/usb/usb-skeleton.c |   10 ++-
 include/linux/usb.h|2 +-
 include/linux/usb/cdc.h|7 ++
 include/linux/usb/ch9.h|   20 +++---
 include/linux/usb/serial.h |6 ++
 include/linux/usb_usual.h  |4 +-
 include/linux/usbdevice_fs.h   |4 +-
 include/scsi/scsi_device.h |1 +
 44 files changed, 532 insertions(+), 170 deletions(-)
 create mode 100644 drivers/usb/misc/berry_charge.c

---

Adrian Bunk (1):
  USB: USB_RTL8150 must select MII

Alan Stern (6):
  EHCI: turn off remote wakeup during shutdown
  USB: unusual_devs update for Sony P990i phone
  usbcore: small changes to hub driver's suspend method
  EHCI: add debugging message to ehci_bus_suspend
  USB: fix concurrent buffer access in the hub driver
  USB: unconfigure devices which have config 0

Andrew Victor (1):
  USB: at91-ohci, handle extra at91sam9261 ahb clock

Bryan O'Donoghue (1):
  USB: fix g_serial small error

David Brownell (4):
  usbnet: recognize SiteCom CN-124
  usbnet: init fault (oops) cleanup, whitespace fixes
  usbnet: add missing Kconfig for KC2190 cables
  USB: at91_udc, shrink runtime footprint

David Hollis (1):
  USB: asix - Fix endian issues in asix_tx_fixup()

Dylan Taft (1):
  USB Storage: US_FL_IGNORE_RESIDUE needed for Aiptek MP3 Player

Greg Kroah-Hartman (1):
  USB: Driver to charge USB blackberry devices

Inaky Perez-Gonzalez (1):
  USB: descriptor structures have to be packed

Ishizaki Kou (1):
  USB: ps3: don't call ps3_system_bus_driver_register on other platforms

Jeremy Roberson (1):
  USB: hid-core.c: Removes GTCO CalComp Interwrite IPanel PIDs from 
blacklist

Joris van Rantwijk (1):
  USB: add flow control to usb-serial generic driver.

Josh Triplett (1):
  USB: In init_endpoint_class, use PTR_ERR to obtain an errno value, not 
IS_ERR

Kevin Lloyd (1):
  usb: Remove Airprime device from option.c

Mike Frysinger (1):
  USB: use __u32 rather than u32 in userspace ioctls in usbdevice_fs.h

Oliver Neukum (5):
  USB: fix needless failure under certain conditions
  USB: fix autosuspend race in skeleton driver
  USB Storage: indistinguishable devices with broken and unbroken firmware
  USB: cdc-acm: fix incorrect throtteling, make set_control optional
  USB: quirky device for cdc-acm

Pete Zaitcev (2):
  USB: Fix error cleanup path in airprime
  USB: make usb_iso_packet_descriptor.status signed

Pozsar Balazs (1):
  USB: another id for cp2101 driver

Prarit Bhargava (1):
  USB: change __init to __devinit for isp116x_probe

Randy Dunlap (2):
  USB: kernel-doc fixes
  USB: ueagle-atm.c needs sched.h

Robert P. J. Day (2):
  USB: Fix 

Re: O2micro smartcard reader driver.

[Markus Rechberger]

Hi,

so finally I'm also looking at that driver,
http://pieleric.free.fr/o2scr/
the driver compiles fine, though it doesn't seem to work (unless I'm
doing something wrong here)

dmesg shows up following entries:

pccard: card ejected from slot 1
PCMCIA: socket c160c364: *** DANGER *** unable to remove socket power
pccard: PCMCIA card inserted into slot 1
pcmcia: registering new device pcmcia1.0
pccard: card ejected from slot 1
PCMCIA: socket c160c364: *** DANGER *** unable to remove socket power
pccard: PCMCIA card inserted into slot 1
pcmcia: registering new device pcmcia1.0
pccard: card ejected from slot 1
PCMCIA: socket c160c364: *** DANGER *** unable to remove socket power
pccard: PCMCIA card inserted into slot 1
pcmcia: registering new device pcmcia1.0
OZSCRLX O2Micro SmartCardBus Reader (for kernel >= 2.6.17)

The module for any reason has a usecount value of 1
ozscrlx21548  1

devicenode /dev/ozscrlx isn't opened anywhere either.

I'll do some further investigations uppon it, I'd also like to see it
directly in the kernel. It would be handy to use for encrypted
filesystems.

Markus


On 12/12/06, Eric Piel <[EMAIL PROTECTED]> wrote:

28.11.2006 12:49, Oliver Neukum wrote/a écrit:
>> Latest version I've published is there:
>> http://pieleric.free.fr/o2scr/
>
> case OZSCR_OPEN: /* Request ICC */
> dprintk("OZSCR_OPEN\n");
> ATRLength = ATR_SIZE;
> pRdrExt->IOBase = (PSCR_REGISTERS *) dev->io_base; //XXX
necessary?
> pRdrExt->membase = dev->am_base; //XXX necessary?
>
> pRdrExt->m_SCard.AvailableProtocol = 0;
> pRdrExt->m_SCard.RqstProtocol = 0;
> dprintk("membase:%p\n", pRdrExt->membase);
> dprintk("ioport:0x%03x\n", (unsigned)pRdrExt->IOBase);
>
> ret = CmdResetReader( pRdrExt, FALSE, ATRBuffer,  );
> apdu.LengthOut = ATRLength;
>
> #ifdef PCMCIA_DEBUG
> printk(KERN_DEBUG "Open finished, ATR buffer = ");
> for( ATRLength = 0; ATRLength < apdu.LengthOut; ATRLength++ )
> printk(" [%02X] ", ATRBuffer[ATRLength] );
> printk("\n");
> #endif
>
> memcpy( apdu.DataOut, ATRBuffer, ATRLength );
> ret = copy_to_user((struct ozscr_apdu *)arg, ,
sizeof(struct ozscr_apdu));
> break;
>
> 1. This needs locking against concurrent ioctls
> 2. The interpretation of copy_to_user()'s return code is incorrect
>

Hi Oliver,

Thanks a lot for reading my code, I didn't even hope that someone would!
I've corrected the copy_to_user (and copy_from_user) code. However I
don't know how to do locking for the concurrent ioctls. Indeed, I don't
think there is anything preventing two programs to call the driver at
the same time. Unfortunately, I've got no idea how to do the locking and
surprisingly couldn't find any ioctl code in the kernel doing locking.
Maybe I've just not looked at the right place, could you give a me some
hint how to do locking for ioctl's ?

See you,
Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/




--
Markus Rechberger
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 07/21] Xen-paravirt: remove ctor for pgd cache

[Jeremy Fitzhardinge]

Christoph Lameter wrote:
> On Thu, 15 Feb 2007, Jeremy Fitzhardinge wrote:
>
>   
>> Remove the ctor for the pgd cache.  There's no point in having the
>> cache machinery do this via an indirect call when all pgd are freed in
>> the one place anyway.
>> 
>
> Great. We finally get rid of this evil . 
>
> On second throughts:
>
> Are you sure that you understand what you are modifying? The ctor is not 
> called when you allocate an object but when the slab allocates it. Freeing 
> an object does not make the slab free it. It will hold it for the next
> kmalloc. So you may just have reduced performance somewhat by addiung 
> additional ctor processing and possibly disturbed the preservation of 
> cache hot pgds.
It's true I wrote this patch as a result of accidentally reading slob.c
rather than slab.c, which was mostly as a result of hopeful thinking (I
knew that there has been discussion about removing all the slab cache
stuff, and I assumed that it had already happened).  As a result I'm
withdrawing this patch for now, but with any luck it will be useful at
some point.

J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas

[Keir Fraser]

On 16/2/07 19:26, "Jeremy Fitzhardinge" <[EMAIL PROTECTED]> wrote:

> Keir Fraser wrote:
>> Hmmm... Actually looks like a bunch of architectures do lazy sync of the
>> vmalloc area, although neither ia64 nor powerpc does so. However, all
>> current users of the alloc_vm_area() function would be okay since none of
>> the other lazy-syncing architectures are supported by Xen.
>>   
> 
> Well, assuming that alloc_vm_area() has some non-Xen use, the right
> thing is for archs to export vmalloc_sync_all(), and just use that from
> common code.

It has no other users right now and get_vm_area_sync() would be a
better-named and more generically useful function than alloc_vm_area(). But
yes, to be done properly it does require vmalloc_sync_all() to be defined by
all architectures (even if that's BUG() and implement-properly-on-demand).

get_vm_area_sync(), partnered with existing remove_vm_area(), just seems
much smaller and neater than adding four new functions with a more complex
usage: alloc_vm_area, {lock,unlock}_vm_area, and free_vm_area. Maybe keeping
free_vm_area() too makes sense as its interface is more neatly symmetrical
to that of get_vm_area().

 -- Keir


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Add .splice_read to sockets?

[Paul P Komkoff Jr]

Hi!

Is there any plans to make splice(socket, ..., pipe, ...) work?

Thanks!

-- 
Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key
 This message represents the official view of the voices in my head
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pata_amd dropping to PIO on resume

[Robert Hancock]

Tobias Diedrich wrote:

Possibly a known issue:

After resume pata_amd drops from UDMA/33 to PIO on my system.
Reloading the module puts both attached optical drives (master and
slave) back to UDMA/33.

AFAICS "simplex DMA is claimed by other device, disabling DMA" seems
to be causing it to drop to PIO (but only after a suspend/resume
cycle, not on boot or module load).

Burning a DVD with 6x speed using PIO makes heavy use of burnproof
and makes the whole system quite sluggish. :)


Yes, the fact that it's going into simplex mode is the problem, it 
wasn't in simplex to start with. It looks like pata_amd does an 
ata_pci_clear_simplex only for certain chip models, maybe this model 
needs it as well?


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Remove stack hard limit on ia64

[Ken Chen]

On 2/16/07, Olaf Hering <[EMAIL PROTECTED]> wrote:

From: [EMAIL PROTECTED]

Un-Breaks pthreads, since Oct 2003.


why aren't you using /etc/security/limits.conf?
I think the stack limit can be set as big as 8TB on ia64 with default
16KB page size.

- Ken
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Fwd: [PATCH] consolidate generic_writepages and mpage_writepages]

[Steve French (smfltc)]

From: Miklos Szeredi <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH] consolidate generic_writepages and mpage_writepages
Date:   Fri, 16 Feb 2007 17:23:25 +0100

From: Miklos Szeredi <[EMAIL PROTECTED]>

Clean up massive code duplication between mpage_writepages() and
generic_writepages().

The new generic function, write_cache_pages() takes a function pointer
argument, which will be called for each page to be written.

Maybe cifs_writepages() too can use this infrastructure, but I'm not
touching that with a ten-foot pole.
 

The cifs case ought to be one of the simpler ones, pseudo-code is pretty 
easy, the hard part is all of the stuff unrelated to cifs:
Ideally if there were generic functions to help out, cifs writepages 
would look roughly like the following


cifs_writepages(struct address_space *mapping, struct writeback_control 
*wbc)

{
  
   while (no more pages to write) {

   /* find writeable file handle for this inode */
   /* find the biggest set of contiguous pages that total less than 
wsize */

   if (packet signing is enabled)
   /* write lock pages so they can not be changed under us 
while we are calculating the checksum */
 
  CIFSSMBWrite2(tree_connection, network_file_handle, array of 
iovecs, number of iovecs);


   if(packet signing was enabled)
   /* unlock pages */

   if(error) {
set page errors
if (mounted "hard" )
  continue; /* retry */
else /* if no retry possible */
  return error to caller;
  }
   update bytes written statistics
   update index to point to next set of pages
   }  /* end while loop */
}


If it were even better, CIFSSMBWrite2 could be called async - so that it 
did not have to wait for a network response from Samba (just an ack from 
TCP), before issuing the next write onto the wire - but this would 
require that we could queue a pointer to a completion routine to the mpx 
entry.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20 kernel hang with USB drive and vfat doing ftruncate

[Robert Hancock]

Kumar Gala wrote:
I'm seeing an issue with a stock 2.6.20 kernel running on an embedded 
PPC.  I've got a usb flash drive plugged in and the filesystem on the 
drive is vfat.  Running with 64M and no swap.


If I execute a series of large (100M+) ftruncate() on the disk the 
kernel will hang and never return.  It seems to be stuck in the idle 
loop().


On FAT filesystems this forces the entire file contents of that size to 
be written out with zeros. Are you sure the kernel just isn't busy 
writing out all that data to the disk?


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] fix SAA7146_CLIPPING_MEM size

[Olaf Hering]

Limit the pci_alloc_consistent size to 128K
PAGE_SIZE can be 64K, which leads to a 896K allocation.

calculate_clipping_registers_rect() uses not more than 257 bytes
because saa7146_video.c:s_fmt limits ov.nclips to 16

But bttv-driver.c does not allow up to 2048 clips in win->clipcount
btcx_screen_clips() may add 4 more clips.

So a max array size of 131329 is enough.
Right now only 56K get allocated.


Signed-off-by: Olaf Hering <[EMAIL PROTECTED]>

---
 include/media/saa7146_vv.h |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Index: linux-2.6/include/media/saa7146_vv.h
===
--- linux-2.6.orig/include/media/saa7146_vv.h
+++ linux-2.6/include/media/saa7146_vv.h
@@ -239,7 +239,8 @@ void saa7146_res_free(struct saa7146_fh 
 #define SAA7146_HPS_SYNC_PORT_B0x01
 
 /* some memory sizes */
-#define SAA7146_CLIPPING_MEM   (14*PAGE_SIZE)
+/* see saa7146_hlp.c:calculate_clipping_registers_rect and 
bttv-driver.c:setup_window */
+#define SAA7146_CLIPPING_MEM   ( ( ( 2048 + 4 ) * ( 2 * (2 * 16) ) ) + 1 )
 
 /* some defines for the various clipping-modes */
 #define SAA7146_CLIPPING_RECT  0x4
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

[Robert Hancock]

linux-os (Dick Johnson) wrote:

Have you tried it recently? Attached is a compressed session


Yes, I have, most recently in 2.6.20. It works fine.


showing 2.6.16.24 compiling fine. Then the same thing is attempted
with 2.6.19. It fails with some "improper configuration" errors.
This script shows that I execute the demanded commands
as 'make oldconfig' and 'make prepare'. Then I try to compile
again resulting, again with the exact same errors.
This was reported on the Linux kernel list and somebody stated,
with much authority BTW, "we don't support out of tree
drivers anymore."


Who told you that? There's documentation in the kernel tree in 
Documentation/kbuild/modules.txt that describes how to set this up properly.


Looking at your output, without knowing what the makefile contents are, 
it's impossible to determine what's going wrong. Likely the makefile is 
trying to do things that the kernel build system should be doing. For a 
simple module called mymodule with files file1.c, file2.c, file3.c you 
need only a makefile like this:


ifneq ($(KERNELRELEASE),)

# kbuild part of makefile
obj-m  := mymodule.o
mymodule-y := file1.o file2.o file3.o

else

# Normal Makefile
KERNELDIR := /lib/modules/`uname -r`/build
all::
$(MAKE) -C $(KERNELDIR) M=`pwd` $@

endif

--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Using sched_clock for mmio-trace

[Daniel Walker]

On Fri, 2007-02-16 at 17:10 -0500, Jeff Muizelaar wrote:

> 
> I still meant for _with_features to have same semantics so calling:
> 
> clocksource_get_clock_with_features(CLOCKSOURCE_PM_UNAFFECTED|CLOCKSOURCE_STABLE
>  |CLOCKSOURC_ATOMIC|CLOCKSOURCE_64BITS|CLOCKSOURCE_CONTINUOUS);
> 
> would be equivalent to calling:
> 
> clocksource_get_masked_clock(CLOCKSOURCE_PM_AFFECTED|CLOCKSOURCE_UNSTABLE
>  |CLOCKSOURC_NOT_ATOMIC|CLOCKSOURCE_64BITS|CLOCKSOURCE_NOT_CONTINUOUS);
> 
> The only difference is that the naming is reversed. i.e. it isn't a
> doulbe negative.

Yes, I assumed that ..

> perhaps a better name would clocksource_get_clock_must_have() or
> clocksource_get_clock_must_be()
>  
> > Gets pretty ugly .. The clocksource interface already has a positive
> > rating to describe the "best" clocks in the system, which is used to
> > return the "best" clock .. Where the maintainers of the system give each
> > clock a rating. I would imagine most people would just get the so called
> > "best" clock which has the best rating..
> > 
> > I'm starting to think this long flags stringing effect could happen with
> > negative flags also, but it's seems a lot less likely.
> 
> The amount of flag stringing should be the same.

I don't think so .. The common case with negative flags is no flags,
then next would be CLOCKSOURCE_UNSTABLE. At most I would guess two
flags .. The other direction your likely to have people using all flags
most of the time. That's why I showed a function call with all the flags
listed.

To be clear the clocksources are already sorted with a rating (no flags
involved). 

So for example, On i386 the clocks are sorts as follows,

tsc (300)
acpi_pm (200)
pit (110)
jiffies (1)

So the bulk of the positive information is already there for you. The
tsc clock is by far the best in the system if it's stable. If you ignore
the flags, then you will always be given the tsc .

> > > instead of
> > > 
> > > clocksource_get_clock_masked(CLOCKSOURCE_UNSTABLE)
> > > clocksource_get_clock_masked(CLOCKSOURCE_PM_AFFECTED)
> > > 
> > > Especially awkward is the CLOCKSOURCE_64BIT flag, as there isn't really
> > > anyway to specify that I want a 64bit timer, only a way to specify that
> > > I don't.
> > 
> > I might add a way to get specific flags, but I still think the flags
> > should be mostly negative features.
> 
> Yeah, the problem is that all of the features are negative except for
> CLOCKSOURCE_64BIT, so you can't mask for it.

It's meant as a negative feature. So you can mask it if you can't handle
the math .. The only 64bit clock I know off is the tsc, and it's got the
highest rating of all clocks.


> It might be good if something like these explanations could be added as
> comments beside the feature flags.

Ok .. On my TODO list ..

> So, if I was a systemtap style user of the clocksource api, I'd still have to
> do something like:
> 
> init() {
>   // assume this gives me the tsc
>   clock = clocksource_get_masked_clock(CLOCKSOURCE_NOT_ATOMIC);
>   register a cpu_freq notifier
> }
> 
> trace() {
>   trace.time =
>   
> compute_cyc2_ns_by_hand_using_info_from_cpu_freq(clocksource_read(clock))
> }
> 
> In this case it doesn't look like using the clocksource stuff helps this
> style of user much as all that is abstracted away is really the reading
> the tsc. On the other hand it sounds like if you want all this stuff
> taken care of for you, most people should be using do_gettimeofday()
> instead.

Instead of using an unstable clock and trying to compensate for it, the
solution is not to use unstable clocks. The clocksource stuff does help
with that.. You can either use the tsc until it becomes unstable, or use
the acpi_pm clock which never becomes unstable. Both are used in the
same way.

> init() {
  // gives you the acpi_pm
  clock = 
clocksource_get_masked_clock(CLOCKSOURCE_PM_AFFECTED|CLOCKSOURCE_NOT_ATOMIC);
>   register a cpu_freq notifier
> }
> 
> trace() {
>   trace.time =
  cyc2ns(clock, clocksource_read(clock))
> }
> 


Daniel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Remove stack hard limit on ia64

[Andrew Morton]

On Fri, 16 Feb 2007 23:06:54 +0100
Olaf Hering <[EMAIL PROTECTED]> wrote:

> From: [EMAIL PROTECTED]
> 
> Un-Breaks pthreads, since Oct 2003.
> 

Oh come on, that's not a changelog.  I refuse to believe that nobody has
used pthreads on ia64 for the past three years.

> 
> Index: linux-2.6/include/asm-ia64/resource.h
> ===
> --- linux-2.6.orig/include/asm-ia64/resource.h
> +++ linux-2.6/include/asm-ia64/resource.h
> @@ -2,7 +2,6 @@
>  #define _ASM_IA64_RESOURCE_H
>  
>  #include 
> -#define _STK_LIM_MAX DEFAULT_USER_STACK_SIZE
>  #include 
>  
>  #endif /* _ASM_IA64_RESOURCE_H */

Please provide a complete description of the problem which this patch is
fixing, and a complete description of how the patch fixes it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

MediaGX/GeodeGX1 requires X86_OOSTORE. (Was: Re: Strange connection slowdown on pcnet32)

[Lennart Sorensen]

On Fri, Feb 16, 2007 at 05:27:28PM -0500, Lennart Sorensen wrote:
> On Fri, Feb 16, 2007 at 04:01:57PM -0500, Lennart Sorensen wrote:
> > It seems whenever it gets stuck, it is always the same descripter it is
> > stuck on.  Here is my current log:
> > 
> > eth1: interrupt  csr0=0x4f3 new csr=0x33, csr3=0x.
> > eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
> > eth1: base: 0x04c51812 status: 8000 next->status: 0340
> > eth1: pcnet32_poll: pcnet32_rx() got 0 packets
> > eth1: interrupt  csr0=0x4f3 new csr=0x33, csr3=0x.
> > eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
> > eth1: base: 0x04c51812 status: 8000 next->status: 0340
> > eth1: pcnet32_poll: pcnet32_rx() got 0 packets
> > eth1: interrupt  csr0=0x4f3 new csr=0x33, csr3=0x.
> > eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
> > eth1: base: 0x04c51812 status: 8000 next->status: 0340
> > eth1: pcnet32_poll: pcnet32_rx() got 0 packets
> > eth1: interrupt  csr0=0x4f3 new csr=0x33, csr3=0x.
> > eth1: exiting interrupt, csr0=0x0433, csr3=0x5f00.
> > eth1: base: 0x04c51812 status: 8000 next->status: 0340
> > eth1: pcnet32_poll: pcnet32_rx() got 0 packets
> > eth1: interrupt  csr0=0x4f3 new csr=0x33, csr3=0x.
> > eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
> > eth1: base: 0x04c51812 status: 8000 next->status: 0340
> > eth1: pcnet32_poll: pcnet32_rx() got 0 packets
> > eth1: interrupt  csr0=0x4f3 new csr=0x33, csr3=0x.
> > eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
> > eth1: base: 0x04c51812 status: 8000 next->status: 0340
> > eth1: pcnet32_poll: pcnet32_rx() got 0 packets
> > eth1: interrupt  csr0=0x4f3 new csr=0x33, csr3=0x.
> > eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
> > eth1: base: 0x04c51812 status: 8000 next->status: 0340
> > eth1: pcnet32_poll: pcnet32_rx() got 0 packets
> > eth1: interrupt  csr0=0x4f3 new csr=0x33, csr3=0x.
> > eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
> > eth1: base: 0x04c51812 status: 8000 next->status: 0340
> > eth1: pcnet32_poll: pcnet32_rx() got 0 packets
> > eth1: interrupt  csr0=0x4f3 new csr=0x33, csr3=0x.
> > eth1: exiting interrupt, csr0=0x0433, csr3=0x5f00.
> > eth1: base: 0x04c51812 status: 8000 next->status: 0340
> > eth1: pcnet32_poll: pcnet32_rx() got 0 packets
> > eth1: interrupt  csr0=0x4f3 new csr=0x33, csr3=0x.
> > eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
> > eth1: base: 0x04c51812 status: 8000 next->status: 0340
> > eth1: pcnet32_poll: pcnet32_rx() got 0 packets
> > eth1: interrupt  csr0=0x4f3 new csr=0x33, csr3=0x.
> > eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
> > eth1: base: 0x04c51812 status: 8000 next->status: 0340
> > eth1: pcnet32_poll: pcnet32_rx() got 0 packets
> > eth1: interrupt  csr0=0x4f3 new csr=0x33, csr3=0x.
> > eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
> > eth1: base: 0x04c51812 status: 8000 next->status: 0340
> > eth1: pcnet32_poll: pcnet32_rx() got 0 packets
> > eth1: interrupt  csr0=0x4f3 new csr=0x33, csr3=0x.
> > eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
> > eth1: base: 0x04c51812 status: 8000 next->status: 0340
> > eth1: pcnet32_poll: pcnet32_rx() got 0 packets
> > eth1: interrupt  csr0=0x4f3 new csr=0x33, csr3=0x.
> > eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
> > eth1: base: 0x04c51812 status: 8000 next->status: 0340
> > eth1: pcnet32_poll: pcnet32_rx() got 0 packets
> > eth1: interrupt  csr0=0x4f3 new csr=0x33, csr3=0x.
> > eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
> > eth1: base: 0x04c51812 status: 8000 next->status: 0340
> > eth1: pcnet32_poll: pcnet32_rx() got 0 packets
> > eth1: interrupt  csr0=0x4f3 new csr=0x33, csr3=0x.
> > eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
> > eth1: base: 0x04c51812 status: 8000 next->status: 0340
> > eth1: pcnet32_poll: pcnet32_rx() got 0 packets
> > eth1: interrupt  csr0=0x4f3 new csr=0x33, csr3=0x.
> > eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
> > eth1: base: 0x04c51812 status: 8000 next->status: 0340
> > eth1: pcnet32_poll: pcnet32_rx() got 0 packets
> > eth1: interrupt  csr0=0x4f3 new csr=0x33, csr3=0x.
> > eth1: exiting interrupt, csr0=0x0433, csr3=0x5f00.
> > eth1: base: 0x04c51812 status: 8000 next->status: 0340
> > eth1: pcnet32_poll: pcnet32_rx() got 0 packets
> > eth1: interrupt  csr0=0x4f3 new csr=0x33, csr3=0x.
> > eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
> > eth1: base: 0x04c51812 status: 8000 next->status: 0340
> > eth1: pcnet32_poll: pcnet32_rx() got 0 packets
> > eth1: interrupt  csr0=0x4f3 new csr=0x33, csr3=0x.
> > eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
> > eth1: base: 0x04c51812 status: 8000 next->status: 0340
> > eth1: pcnet32_poll: pcnet32_rx() got 0 packets
> > eth1: interrupt  csr0=0x4f3 new csr=0x33, csr3=0x.
> > eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
> > eth1: base: 0x04c51812 status: 8000 next->status: 0340
> > 

[PATCH] free swap space when (re)activating page

[Rik van Riel]

The attached patch does what I described in the other thread, it
makes the pageout code free swap space when swap is getting full,
by taking away the swap space from pages that get moved onto or
back onto the active list.

In some tests on a system with 2GB RAM and 1GB swap, it kept the
free swap at 500MB for a 2.3GB qsbench, while without the patch
over 950MB of swap was in use all of the time.

This should give kswapd more flexibility in what to swap out.

What do you think?

Signed-off-by: Rik van Riel <[EMAIL PROTECTED]>

--
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.
--- linux-2.6.20.x86_64/mm/vmscan.c.swapfull	2007-02-16 06:47:02.0 -0500
+++ linux-2.6.20.x86_64/mm/vmscan.c	2007-02-16 07:03:30.0 -0500
@@ -587,6 +587,9 @@ free_it:
 		continue;
 
 activate_locked:
+		/* Not a candidate for swapping, so reclaim swap space. */
+		if (PageSwapCache(page) && vm_swap_full())
+			remove_exclusive_swap_page(page);
 		SetPageActive(page);
 		pgactivate++;
 keep_locked:
@@ -875,6 +878,11 @@ force_reclaim_mapped:
 		pagevec_strip();
 		spin_lock_irq(>lru_lock);
 	}
+	if (vm_swap_full()) {
+		spin_unlock_irq(>lru_lock);
+		pagevec_swap_free();
+		spin_lock_irq(>lru_lock);
+	}
 
 	pgmoved = 0;
 	while (!list_empty(_active)) {
--- linux-2.6.20.x86_64/mm/swap.c.swapfull	2007-02-16 07:09:38.0 -0500
+++ linux-2.6.20.x86_64/mm/swap.c	2007-02-16 07:05:00.0 -0500
@@ -420,6 +420,24 @@ void pagevec_strip(struct pagevec *pvec)
 	}
 }
 
+/*
+ * Try to free swap space from the pages in a pagevec
+ */
+void pagevec_swap_free(struct pagevec *pvec)
+{
+	int i;
+
+	for (i = 0; i < pagevec_count(pvec); i++) {
+		struct page *page = pvec->pages[i];
+
+		if (PageSwapCache(page) && !TestSetPageLocked(page)) {
+			if (PageSwapCache(page))
+remove_exclusive_swap_page(page);
+			unlock_page(page);
+		}
+	}
+}
+
 /**
  * pagevec_lookup - gang pagecache lookup
  * @pvec:	Where the resulting pages are placed
--- linux-2.6.20.x86_64/include/linux/pagevec.h.swapfull	2007-02-16 07:06:29.0 -0500
+++ linux-2.6.20.x86_64/include/linux/pagevec.h	2007-02-16 07:06:41.0 -0500
@@ -26,6 +26,7 @@ void __pagevec_free(struct pagevec *pvec
 void __pagevec_lru_add(struct pagevec *pvec);
 void __pagevec_lru_add_active(struct pagevec *pvec);
 void pagevec_strip(struct pagevec *pvec);
+void pagevec_swap_free(struct pagevec *pvec);
 unsigned pagevec_lookup(struct pagevec *pvec, struct address_space *mapping,
 		pgoff_t start, unsigned nr_pages);
 unsigned pagevec_lookup_tag(struct pagevec *pvec,

Re: [2.6.20-get13] KVM-12 won't build

[Bill Davidsen]

Joerg Roedel wrote:

On Fri, Feb 16, 2007 at 11:32:13AM -0500, Bill Davidsen wrote:
  

Goes out with an error message:

   cc -I /home/davidsen/downloads/kernel.org/linux-2.6.20-git13/include -MMD -MF ./.kvmctl.d 
-g   -c -o kvmctl.o kvmctl.c

   kvmctl.c:29:2: error: #error libkvm: userspace and kernel version mismatch
   make[1]: *** [kvmctl.o] Error 1
 
I don't see a kvm-13 on the KVM website.



You will find the kvm-13 release in the SourceForge download area of
KVM[1]. Kvm-12 is still required for 2.6.20 kernels.

Joerg

[1] http://sourceforge.net/project/showfiles.php?group_id=180599

  

I'll look, the download off the home page didn't seem to have it.

--
bill davidsen <[EMAIL PROTECTED]>
 CTO TMR Associates, Inc
 Doing interesting things with small computers since 1979

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/