Re: Inotify problem [was Re: 2.6.13-rc6-mm1]

[Robert Love]

On Fri, 2005-08-26 at 13:52 -0400, John McCutchan wrote:

> Thanks for your suggestion, it has fixed the inotify problem. But where
> to put the fix is turning into a bit of a mess. Some callers like
> drivers/md/dm.c:682 call idr_get_new_above as if it will return >=
> starting_id. The comment says that it will return > starting_id, and the
> function name leads people to believe the same thing. In the patch below
> I change inotify do add one to the value was pass into idr. I also
> change the comment to more accurately reflect what the function does.
> The function name doesn't fit, but it never did.
> 
> Signed-off-by: John McCutchan <[EMAIL PROTECTED]>

Signed-off-by: Robert Love <[EMAIL PROTECTED]>

Keeping the current behavior is probably the best way to go.

Robert Love

> Index: linux/fs/inotify.c
> ===
> --- linux.orig/fs/inotify.c   2005-08-26 13:38:29.0 -0400
> +++ linux/fs/inotify.c2005-08-26 13:38:55.0 -0400
> @@ -353,7 +353,7 @@
>   do {
>   if (unlikely(!idr_pre_get(&dev->idr, GFP_KERNEL)))
>   return -ENOSPC;
> - ret = idr_get_new_above(&dev->idr, watch, dev->last_wd, 
> &watch->wd);
> + ret = idr_get_new_above(&dev->idr, watch, dev->last_wd+1, 
> &watch->wd);
>   } while (ret == -EAGAIN);
>  
>   return ret;
> Index: linux/lib/idr.c
> ===
> --- linux.orig/lib/idr.c  2005-08-26 13:38:22.0 -0400
> +++ linux/lib/idr.c   2005-08-26 13:39:08.0 -0400
> @@ -207,7 +207,7 @@
>  }
>  
>  /**
> - * idr_get_new_above - allocate new idr entry above a start id
> + * idr_get_new_above - allocate new idr entry above or equal to a start id
>   * @idp: idr handle
>   * @ptr: pointer you want associated with the ide
>   * @start_id: id to start search at
> 

-
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: Inotify problem [was Re: 2.6.13-rc6-mm1]

[John McCutchan]

On Fri, 2005-08-26 at 13:03 -0400, Jim Houston wrote:
> Hi Everyone,
> 
> I'm answering this from my home email. I have not heard from my
> co-workers in Florida yet, and I imagine that they are busy cleaning up
> after hurricane Katrina and waiting for the power to come back on.
> 
> It looks like we have an "off by one" problem with idr_get_new_above()
> which may be part of the inotify problem.  I'm not sure if the problem
> is the behavior or the name & comments.  The start_id parameter is the
> starting point for the idr allocation search, and if it is available, it
> will be allocated.  If you pass in the last id allocated as the start_id
> and it has already been freed (by an idr_remove call), it will be
> allocated again.  The obvious fix would be to increment start_id
> in idr_get_new_above().

Thanks for your suggestion, it has fixed the inotify problem. But where
to put the fix is turning into a bit of a mess. Some callers like
drivers/md/dm.c:682 call idr_get_new_above as if it will return >=
starting_id. The comment says that it will return > starting_id, and the
function name leads people to believe the same thing. In the patch below
I change inotify do add one to the value was pass into idr. I also
change the comment to more accurately reflect what the function does.
The function name doesn't fit, but it never did.

Signed-off-by: John McCutchan <[EMAIL PROTECTED]>

Index: linux/fs/inotify.c
===
--- linux.orig/fs/inotify.c 2005-08-26 13:38:29.0 -0400
+++ linux/fs/inotify.c  2005-08-26 13:38:55.0 -0400
@@ -353,7 +353,7 @@
do {
if (unlikely(!idr_pre_get(&dev->idr, GFP_KERNEL)))
return -ENOSPC;
-   ret = idr_get_new_above(&dev->idr, watch, dev->last_wd, 
&watch->wd);
+   ret = idr_get_new_above(&dev->idr, watch, dev->last_wd+1, 
&watch->wd);
} while (ret == -EAGAIN);
 
return ret;
Index: linux/lib/idr.c
===
--- linux.orig/lib/idr.c2005-08-26 13:38:22.0 -0400
+++ linux/lib/idr.c 2005-08-26 13:39:08.0 -0400
@@ -207,7 +207,7 @@
 }
 
 /**
- * idr_get_new_above - allocate new idr entry above a start id
+ * idr_get_new_above - allocate new idr entry above or equal to a start id
  * @idp: idr handle
  * @ptr: pointer you want associated with the ide
  * @start_id: id to start search at

-
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: Inotify problem [was Re: 2.6.13-rc6-mm1]

[Jim Houston]

Hi Everyone,

I'm answering this from my home email. I have not heard from my
co-workers in Florida yet, and I imagine that they are busy cleaning up
after hurricane Katrina and waiting for the power to come back on.

It looks like we have an "off by one" problem with idr_get_new_above()
which may be part of the inotify problem.  I'm not sure if the problem
is the behavior or the name & comments.  The start_id parameter is the
starting point for the idr allocation search, and if it is available, it
will be allocated.  If you pass in the last id allocated as the start_id
and it has already been freed (by an idr_remove call), it will be
allocated again.  The obvious fix would be to increment start_id
in idr_get_new_above().

I would be glad to spend some time looking at the inotify problem
assuming that fixing the off-by-one problem above doesn't solve
it.  I have not used inotify and would need pointers to the user
space header files and library.

Jim








-
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: Inotify problem [was Re: 2.6.13-rc6-mm1]

[Johannes Berg]

On Thu, 2005-08-25 at 16:10 -0700, George Anzinger wrote:

> That IS strange.  1024 is on a "level" boundry, but then next level is 
> 2**15, not 2**11.  I will take a look.

Remember that the level is never filled, so maybe the smallest level
just gets an offset or something? Well, you're the expert I suppose, so
apologies if this didn't make sense. Just crossed my mind :)

johannes


signature.asc
Description: This is a digitally signed message part

Re: Inotify problem [was Re: 2.6.13-rc6-mm1]

[George Anzinger]

John McCutchan wrote:

On Thu, 2005-08-25 at 11:54 -0700, George Anzinger wrote:


Robert Love wrote:


On Thu, 2005-08-25 at 09:33 -0400, John McCutchan wrote:



On Thu, 2005-08-25 at 22:07 +1200, Reuben Farrelly wrote:

~
I think the best thing is to take idr into user space and emulate the 
problem usage.  To this end, from the log it appears that you _might_ be 
moving between 0, 1 and 2 entries increasing the number each time.  It 
also appears that the failure happens here:

add 1023
add 1024
find 1024  or is it the remove that fails?  It also looks like 1024 got 
allocated twice.  Am I reading the log correctly?



You are reading the log correctly. There are two bugs. One is that if we
pass X to idr_get_new_above, it can return X again (doesn't ever seem to
return < X). The other problem is that the find fails on 1024 (and 2048
if we skip 1024).


That IS strange.  1024 is on a "level" boundry, but then next level is 
2**15, not 2**11.  I will take a look.





So, is it correct to assume that the tree is empty save these two at 
this time?  I am just trying to figure out what the test program needs 
to do.



Yes that is the exact scenario. Only 2 id's are used at any given time,
and once we hit 1024 things break. This doesn't happen when the tree is
not empty.

Thanks for looking at this!


--
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/
-
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: Inotify problem [was Re: 2.6.13-rc6-mm1]

[Johannes Berg]

On Thu, 2005-08-25 at 11:54 -0700, George Anzinger wrote:

> I think the best thing is to take idr into user space and emulate the 
> problem usage.  

Good plan, I guess. Do you think that's easy?

> To this end, from the log it appears that you _might_ be 
> moving between 0, 1 and 2 entries increasing the number each time.  It 
> also appears that the failure happens here:
> add 1023
> add 1024
> find 1024  or is it the remove that fails?  It also looks like 1024 got 
> allocated twice.  Am I reading the log correctly?

Remove 1024 fails, but add(please make it >1024) seems to return 1024,
and find(1024) also seems to fail. Well, remove() probably has to
find(), but I'm not really sure what inotify does (maybe find first, to
see if it's valid).

> So, is it correct to assume that the tree is empty save these two at 
> this time?  I am just trying to figure out what the test program needs 
> to do.

Yes, but all the smaller ones have been in it at some point in time.

johannes


signature.asc
Description: This is a digitally signed message part

Re: Inotify problem [was Re: 2.6.13-rc6-mm1]

[John McCutchan]

On Thu, 2005-08-25 at 21:03 +0200, Johannes Berg wrote:
> On Thu, 2005-08-25 at 11:54 -0700, George Anzinger wrote:
> 
> > I think the best thing is to take idr into user space and emulate the 
> > problem usage.  
> 
> Good plan, I guess. Do you think that's easy?
> 
> > To this end, from the log it appears that you _might_ be 
> > moving between 0, 1 and 2 entries increasing the number each time.  It 
> > also appears that the failure happens here:
> > add 1023
> > add 1024
> > find 1024  or is it the remove that fails?  It also looks like 1024 got 
> > allocated twice.  Am I reading the log correctly?
> 
> Remove 1024 fails, but add(please make it >1024) seems to return 1024,
> and find(1024) also seems to fail. Well, remove() probably has to
> find(), but I'm not really sure what inotify does (maybe find first, to
> see if it's valid).

Just to clarify, the remove() he is talking about isn't idr_remove, it
is inotify's remove. idr_find() is failing at 1024 which causes
inotify's remove to fail.

-- 
John McCutchan <[EMAIL PROTECTED]>
-
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: Inotify problem [was Re: 2.6.13-rc6-mm1]

[John McCutchan]

On Thu, 2005-08-25 at 11:54 -0700, George Anzinger wrote:
> Robert Love wrote:
> > On Thu, 2005-08-25 at 09:33 -0400, John McCutchan wrote:
> > 
> >>On Thu, 2005-08-25 at 22:07 +1200, Reuben Farrelly wrote:
> >>
> ~
> >>>dovecot: Aug 25 19:31:26 Warning: IMAP(gilly): removing wd 1022 from 
> >>>inotify fd 4
> >>>dovecot: Aug 25 19:31:27 Warning: IMAP(gilly): inotify_add_watch returned 
> >>>1023
> >>>dovecot: Aug 25 19:31:27 Warning: IMAP(gilly): inotify_add_watch returned 
> >>>1024
> >>>dovecot: Aug 25 19:31:27 Warning: IMAP(gilly): removing wd 1024 from 
> >>>inotify fd 4
> >>>dovecot: Aug 25 19:31:27 Error: IMAP(gilly): inotify_rm_watch() failed: 
> >>>Invalid argument
> >>>dovecot: Aug 25 19:31:27 Warning: IMAP(gilly): removing wd 1023 from 
> >>>inotify fd 4
> >>>dovecot: Aug 25 19:31:28 Warning: IMAP(gilly): inotify_add_watch returned 
> >>>1024
> >>>dovecot: Aug 25 19:31:28 Warning: IMAP(gilly): inotify_add_watch returned 
> >>>1024
> >>>
> >>>Note the incrementing wd value even though we are removing them as we go..
> >>>
> >>
> >>What kernel are you running? The wd's should ALWAYS be incrementing, you
> >>should never get the same wd as you did before. From your log, you are
> >>getting the same wd (after you inotify_rm_watch it). I can reproduce
> >>this bug on 2.6.13-rc7.
> >>
> >>idr_get_new_above 
> >>
> >>isn't returning something above.
> >>
> >>Also, the idr layer seems to be breaking when we pass in 1024. I can
> >>reproduce that on my 2.6.13-rc7 system as well.
> >>
> >>
> >>>This is using latest CVS of dovecot code and with 2.6.12-rc6-mm(1|2) 
> >>>kernel.
> >>>
> >>>Robert, John, what do you think?   Is this possibly related to the oops 
> >>>seen 
> >>>in the log that I reported earlier?  (Which is still showing up 2-3 times 
> >>>per 
> >>>day, btw)
> >>
> >>There is definitely something broken here.
> > 
> > 
> > Jim, George-
> > 
> > We are seeing a problem in the idr layer.  If we do idr_find(1024) when,
> > say, a low valued idr, like, zero, is unallocated, NULL is returned.
> 
> I think the best thing is to take idr into user space and emulate the 
> problem usage.  To this end, from the log it appears that you _might_ be 
> moving between 0, 1 and 2 entries increasing the number each time.  It 
> also appears that the failure happens here:
> add 1023
> add 1024
> find 1024  or is it the remove that fails?  It also looks like 1024 got 
> allocated twice.  Am I reading the log correctly?

You are reading the log correctly. There are two bugs. One is that if we
pass X to idr_get_new_above, it can return X again (doesn't ever seem to
return < X). The other problem is that the find fails on 1024 (and 2048
if we skip 1024).

> 
> So, is it correct to assume that the tree is empty save these two at 
> this time?  I am just trying to figure out what the test program needs 
> to do.

Yes that is the exact scenario. Only 2 id's are used at any given time,
and once we hit 1024 things break. This doesn't happen when the tree is
not empty.

Thanks for looking at this!
-- 
John McCutchan <[EMAIL PROTECTED]>
-
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: Inotify problem [was Re: 2.6.13-rc6-mm1]

[George Anzinger]

Robert Love wrote:

On Thu, 2005-08-25 at 09:33 -0400, John McCutchan wrote:


On Thu, 2005-08-25 at 22:07 +1200, Reuben Farrelly wrote:


~

dovecot: Aug 25 19:31:26 Warning: IMAP(gilly): removing wd 1022 from inotify fd 
4
dovecot: Aug 25 19:31:27 Warning: IMAP(gilly): inotify_add_watch returned 1023
dovecot: Aug 25 19:31:27 Warning: IMAP(gilly): inotify_add_watch returned 1024
dovecot: Aug 25 19:31:27 Warning: IMAP(gilly): removing wd 1024 from inotify fd 
4
dovecot: Aug 25 19:31:27 Error: IMAP(gilly): inotify_rm_watch() failed: 
Invalid argument

dovecot: Aug 25 19:31:27 Warning: IMAP(gilly): removing wd 1023 from inotify fd 
4
dovecot: Aug 25 19:31:28 Warning: IMAP(gilly): inotify_add_watch returned 1024
dovecot: Aug 25 19:31:28 Warning: IMAP(gilly): inotify_add_watch returned 1024

Note the incrementing wd value even though we are removing them as we go..



What kernel are you running? The wd's should ALWAYS be incrementing, you
should never get the same wd as you did before. From your log, you are
getting the same wd (after you inotify_rm_watch it). I can reproduce
this bug on 2.6.13-rc7.

idr_get_new_above 


isn't returning something above.

Also, the idr layer seems to be breaking when we pass in 1024. I can
reproduce that on my 2.6.13-rc7 system as well.



This is using latest CVS of dovecot code and with 2.6.12-rc6-mm(1|2) kernel.

Robert, John, what do you think?   Is this possibly related to the oops seen 
in the log that I reported earlier?  (Which is still showing up 2-3 times per 
day, btw)


There is definitely something broken here.



Jim, George-

We are seeing a problem in the idr layer.  If we do idr_find(1024) when,
say, a low valued idr, like, zero, is unallocated, NULL is returned.


I think the best thing is to take idr into user space and emulate the 
problem usage.  To this end, from the log it appears that you _might_ be 
moving between 0, 1 and 2 entries increasing the number each time.  It 
also appears that the failure happens here:

add 1023
add 1024
find 1024  or is it the remove that fails?  It also looks like 1024 got 
allocated twice.  Am I reading the log correctly?


So, is it correct to assume that the tree is empty save these two at 
this time?  I am just trying to figure out what the test program needs 
to do.




--
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/
-
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: Inotify problem [was Re: 2.6.13-rc6-mm1]

[Robert Love]

On Thu, 2005-08-25 at 09:33 -0400, John McCutchan wrote:
> On Thu, 2005-08-25 at 22:07 +1200, Reuben Farrelly wrote:
> > Hi,
> > 
> > I have also observed another problem with inotify with dovecot - so I spoke 
> > with Johannes Berg who wrote the inotify code in dovecot.  He suggested I 
> > post 
> > here to LKML since his opinion is that this to be a kernel bug.
> > 
> > The problem I am observing is this, logged by dovecot after a period of 
> > time 
> > when a client is connected:
> > 
> > dovecot: Aug 22 14:31:23 Error: IMAP(gilly): inotify_rm_watch() failed: 
> > Invalid argument
> > dovecot: Aug 22 14:31:23 Error: IMAP(gilly): inotify_rm_watch() failed: 
> > Invalid argument
> > dovecot: Aug 22 14:31:23 Error: IMAP(gilly): inotify_rm_watch() failed: 
> > Invalid argument
> > 
> > Multiply that by about 1000 ;-)
> > 
> > Some debugging shows this:
> > dovecot: Aug 25 19:31:22 Warning: IMAP(gilly): removing wd 1019 from 
> > inotify fd 4
> > dovecot: Aug 25 19:31:22 Warning: IMAP(gilly): removing wd 1018 from 
> > inotify fd 4
> > dovecot: Aug 25 19:31:22 Warning: IMAP(gilly): inotify_add_watch returned 
> > 1019
> > dovecot: Aug 25 19:31:22 Warning: IMAP(gilly): inotify_add_watch returned 
> > 1020
> > dovecot: Aug 25 19:31:23 Warning: IMAP(gilly): removing wd 1020 from 
> > inotify fd 4
> > dovecot: Aug 25 19:31:23 Warning: IMAP(gilly): removing wd 1019 from 
> > inotify fd 4
> > dovecot: Aug 25 19:31:24 Warning: IMAP(gilly): inotify_add_watch returned 
> > 1020
> 
> 
> 
> > dovecot: Aug 25 19:31:24 Warning: IMAP(gilly): inotify_add_watch returned 
> > 1021
> > dovecot: Aug 25 19:31:24 Warning: IMAP(gilly): removing wd 1021 from 
> > inotify fd 4
> > dovecot: Aug 25 19:31:24 Warning: IMAP(gilly): removing wd 1020 from 
> > inotify fd 4
> > dovecot: Aug 25 19:31:25 Warning: IMAP(gilly): inotify_add_watch returned 
> > 1021
> > dovecot: Aug 25 19:31:25 Warning: IMAP(gilly): inotify_add_watch returned 
> > 1022
> > dovecot: Aug 25 19:31:25 Warning: IMAP(gilly): removing wd 1022 from 
> > inotify fd 4
> > dovecot: Aug 25 19:31:25 Warning: IMAP(gilly): removing wd 1021 from 
> > inotify fd 4
> > dovecot: Aug 25 19:31:26 Warning: IMAP(gilly): inotify_add_watch returned 
> > 1022
> > dovecot: Aug 25 19:31:26 Warning: IMAP(gilly): inotify_add_watch returned 
> > 1023
> > dovecot: Aug 25 19:31:26 Warning: IMAP(gilly): removing wd 1023 from 
> > inotify fd 4
> > dovecot: Aug 25 19:31:26 Warning: IMAP(gilly): removing wd 1022 from 
> > inotify fd 4
> > dovecot: Aug 25 19:31:27 Warning: IMAP(gilly): inotify_add_watch returned 
> > 1023
> > dovecot: Aug 25 19:31:27 Warning: IMAP(gilly): inotify_add_watch returned 
> > 1024
> > dovecot: Aug 25 19:31:27 Warning: IMAP(gilly): removing wd 1024 from 
> > inotify fd 4
> > dovecot: Aug 25 19:31:27 Error: IMAP(gilly): inotify_rm_watch() failed: 
> > Invalid argument
> > dovecot: Aug 25 19:31:27 Warning: IMAP(gilly): removing wd 1023 from 
> > inotify fd 4
> > dovecot: Aug 25 19:31:28 Warning: IMAP(gilly): inotify_add_watch returned 
> > 1024
> > dovecot: Aug 25 19:31:28 Warning: IMAP(gilly): inotify_add_watch returned 
> > 1024
> > 
> > Note the incrementing wd value even though we are removing them as we go..
> > 
> 
> What kernel are you running? The wd's should ALWAYS be incrementing, you
> should never get the same wd as you did before. From your log, you are
> getting the same wd (after you inotify_rm_watch it). I can reproduce
> this bug on 2.6.13-rc7.
> 
> idr_get_new_above 
> 
> isn't returning something above.
> 
> Also, the idr layer seems to be breaking when we pass in 1024. I can
> reproduce that on my 2.6.13-rc7 system as well.
> 
> > This is using latest CVS of dovecot code and with 2.6.12-rc6-mm(1|2) kernel.
> > 
> > Robert, John, what do you think?   Is this possibly related to the oops 
> > seen 
> > in the log that I reported earlier?  (Which is still showing up 2-3 times 
> > per 
> > day, btw)
> 
> There is definitely something broken here.

Jim, George-

We are seeing a problem in the idr layer.  If we do idr_find(1024) when,
say, a low valued idr, like, zero, is unallocated, NULL is returned.

This readily manifests itself in inotify, where we recently switched to
using idr_get_new_above() with our last allocated token.

Robert Love


-
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: Inotify problem [was Re: 2.6.13-rc6-mm1]

[John McCutchan]

On Thu, 2005-08-25 at 16:41 +0200, Johannes Berg wrote:
> On Thu, 2005-08-25 at 10:13 -0400, John McCutchan wrote:
> 
> > I really don't want 2.6.13 to go out with this bug or the compromise. If
> > we use 0, we will have a lot of wd re-use. Which will cause "strange"
> > problems in inotify using applications that cleanup upon receipt of an
> > IN_IGNORE event.
> 
> What happens when, given bug-free code that doesn't reuse, you hit the
> 8192 limit with wd, even if they're not all open at the same time? Does
> it still add them, or will inotify give an error? And does the idr layer
> handle something like that gracefully without using lots of memory?
> 

The 8192 limit is the total watches in use at one time. If over time,
you use more than 8192 watches but not all at one time you will just
keep getting higher and higher wd's. I'm not 100% sure if idr handles it
gracefully. 

> The background is that the process using this is potentially quite
> long-running and keeps opening/closing wds, so 8192 doesn't sound like a
> high barrier, after all Reuben observed hitting the 1024 limit after 15
> minutes or so.

There isn't a 1024 limit, that is a bug in the idr code. He got to that
number by having used 1024 wd's throughout the life of the program.'


FYI, if we pass 0 to idr_get_new_above, both your test programs work
fine. But the first one re-uses wd's (back and forth between 0 & 1).

-- 
John McCutchan <[EMAIL PROTECTED]>
-
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: Inotify problem [was Re: 2.6.13-rc6-mm1]

[Johannes Berg]

On Thu, 2005-08-25 at 10:13 -0400, John McCutchan wrote:

> I really don't want 2.6.13 to go out with this bug or the compromise. If
> we use 0, we will have a lot of wd re-use. Which will cause "strange"
> problems in inotify using applications that cleanup upon receipt of an
> IN_IGNORE event.

What happens when, given bug-free code that doesn't reuse, you hit the
8192 limit with wd, even if they're not all open at the same time? Does
it still add them, or will inotify give an error? And does the idr layer
handle something like that gracefully without using lots of memory?

The background is that the process using this is potentially quite
long-running and keeps opening/closing wds, so 8192 doesn't sound like a
high barrier, after all Reuben observed hitting the 1024 limit after 15
minutes or so.

johannes


signature.asc
Description: This is a digitally signed message part

Re: Inotify problem [was Re: 2.6.13-rc6-mm1]

[John McCutchan]

On Thu, 2005-08-25 at 16:13 +0200, Johannes Berg wrote:
> On Thu, 2005-08-25 at 10:06 -0400, John McCutchan wrote:
> > > it fails on 2.6.13-rc6 as soon as the device is full and doesn't hold
> > > any more directories.
> 
> Obviously this wasn't true, I was hitting the 8192 watches limit and
> misinterpreted the error message. I just tested up to 10 watches
> with this program.

Thanks. The program runs fine, it climbs up until 8192. This confirmed a
hunch I had. The problem only manifests itself when the lower idr
numbers aren't actually being used. The thread
http://www.redhat.com/archives/dm-devel/2004-July/msg3.html seems
somewhat related to this problem, but it suggests that this was fixed in
2.6.7.

-- 
John McCutchan <[EMAIL PROTECTED]>
-
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: Inotify problem [was Re: 2.6.13-rc6-mm1]

[Johannes Berg]

On Thu, 2005-08-25 at 10:06 -0400, John McCutchan wrote:
> > it fails on 2.6.13-rc6 as soon as the device is full and doesn't hold
> > any more directories.

Obviously this wasn't true, I was hitting the 8192 watches limit and
misinterpreted the error message. I just tested up to 10 watches
with this program.

> Could you send me the new test program?

Below.

johannes

/* Author: Johannes Berg <[EMAIL PROTECTED]>
 *
 * This is another small inotify test program that simply
 * repeatedly adds watches.
 */

#include 
#include 
#include 

int main()
{
int fd;
int wd1, wd2;
int ret, i = 0;
char buf[1024];

fd = inotify_init();

if (fd < 0)
perror("inotify_init");

printf("inotify_init returned fd %d\n", fd);

mkdir("/tmp/inotify-test-dir-rm-rf-this", 0777);

while (1) {
i++;

snprintf(buf,sizeof(buf),"/tmp/inotify-test-dir-rm-rf-this/%d",i>>10);
mkdir(buf,0777);

snprintf(buf,sizeof(buf),"/tmp/inotify-test-dir-rm-rf-this/%d/%d",i>>10,i);
mkdir(buf, 0777);
wd1 = inotify_add_watch(fd, buf, IN_ALL_EVENTS);

if (wd1 < 0) {
perror("inotify_add_watch");
break;
}
printf("inotify_add_watch returned wd1 %d\n", wd1);
}
}



signature.asc
Description: This is a digitally signed message part

Re: Inotify problem [was Re: 2.6.13-rc6-mm1]

[John McCutchan]

On Thu, 2005-08-25 at 09:47 -0400, Robert Love wrote:
> On Thu, 2005-08-25 at 09:40 -0400, John McCutchan wrote:
> 
> > I get that message a lot. I know I have said this before (and was wrong)
> > but I think the idr layer is busted.
> 
> This time I think I agree with you.  ;-)
> 
> Let's just pass zero for the "above" parameter in idr_get_new_above(),
> which is I believe the behavior of the other interface, and see if the
> 1024-multiple problem goes away.  We definitely did not have that
> before.
> 

I will test this.

> If it does, and we don't have another solution, let's run with that for
> 2.6.13.  I don't want this bug released.

I really don't want 2.6.13 to go out with this bug or the compromise. If
we use 0, we will have a lot of wd re-use. Which will cause "strange"
problems in inotify using applications that cleanup upon receipt of an
IN_IGNORE event.

The problem will manifest it self when a program does this:

inotify_add_watch "/x" returns 1
inotify_rm_watch 1
[IN_IGNORE event is queued with wd == 1]
inotify_add_watch "/y" returns 1
application reads events
cleans up data structures associated with wd == 1.

-- 
John McCutchan <[EMAIL PROTECTED]>
-
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: Inotify problem [was Re: 2.6.13-rc6-mm1]

[John McCutchan]

On Thu, 2005-08-25 at 16:03 +0200, Johannes Berg wrote:
> On Thu, 2005-08-25 at 09:47 -0400, Robert Love wrote:
> 
> > Let's just pass zero for the "above" parameter in idr_get_new_above(),
> > which is I believe the behavior of the other interface, and see if the
> > 1024-multiple problem goes away.  We definitely did not have that
> > before.
> 
> Will we then need to test if it fails for more than 1024 watches?
> 
> If I adjust the program to
> 
> 1) create /tmp/test/%d
> 2) watch /tmp/test/%d
> 3) repeat
> 
> it fails on 2.6.13-rc6 as soon as the device is full and doesn't hold
> any more directories.

Could you send me the new test program?

-- 
John McCutchan <[EMAIL PROTECTED]>
-
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: Inotify problem [was Re: 2.6.13-rc6-mm1]

[Johannes Berg]

On Thu, 2005-08-25 at 09:47 -0400, Robert Love wrote:

> Let's just pass zero for the "above" parameter in idr_get_new_above(),
> which is I believe the behavior of the other interface, and see if the
> 1024-multiple problem goes away.  We definitely did not have that
> before.

Will we then need to test if it fails for more than 1024 watches?

If I adjust the program to

1) create /tmp/test/%d
2) watch /tmp/test/%d
3) repeat

it fails on 2.6.13-rc6 as soon as the device is full and doesn't hold
any more directories.

johannes


signature.asc
Description: This is a digitally signed message part

Re: Inotify problem [was Re: 2.6.13-rc6-mm1]

[John McCutchan]

On Thu, 2005-08-25 at 15:50 +0200, Johannes Berg wrote:
> On Thu, 2005-08-25 at 09:40 -0400, John McCutchan wrote:
> 
> > On 2.6.13-rc7 the test program fails. It always fails when a wd == 1024.
> > If I skip inotify_rm_watch when wd == 1024, it will fail at wd == 2048.
> > It seems the idr layer has an aversion to multiples of 1024.
> > 
> > When I run your test program I get this a lot:
> 
> I forgot to mention this -- but I just get (on -rc6):
> 
> inotify_add_watch returned wd1 0
> inotify_add_watch returned wd2 1
> inotify_add_watch returned wd1 0
> inotify_add_watch returned wd2 1
> inotify_add_watch returned wd1 0
> inotify_add_watch returned wd2 1

Yeah, pre -rc7 we were always passing in 0 to idr_get_new_above. With
rc7 we pass in the last wd returned.

-- 
John McCutchan <[EMAIL PROTECTED]>
-
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: Inotify problem [was Re: 2.6.13-rc6-mm1]

[Johannes Berg]

On Thu, 2005-08-25 at 09:40 -0400, John McCutchan wrote:

> On 2.6.13-rc7 the test program fails. It always fails when a wd == 1024.
> If I skip inotify_rm_watch when wd == 1024, it will fail at wd == 2048.
> It seems the idr layer has an aversion to multiples of 1024.
> 
> When I run your test program I get this a lot:

I forgot to mention this -- but I just get (on -rc6):

inotify_add_watch returned wd1 0
inotify_add_watch returned wd2 1
inotify_add_watch returned wd1 0
inotify_add_watch returned wd2 1
inotify_add_watch returned wd1 0
inotify_add_watch returned wd2 1

etc.

IOW, they are directly reused, not even with the +1 offset you were
seeing.

johannes


signature.asc
Description: This is a digitally signed message part

Re: Inotify problem [was Re: 2.6.13-rc6-mm1]

[Robert Love]

On Thu, 2005-08-25 at 09:40 -0400, John McCutchan wrote:

> I get that message a lot. I know I have said this before (and was wrong)
> but I think the idr layer is busted.

This time I think I agree with you.  ;-)

Let's just pass zero for the "above" parameter in idr_get_new_above(),
which is I believe the behavior of the other interface, and see if the
1024-multiple problem goes away.  We definitely did not have that
before.

If it does, and we don't have another solution, let's run with that for
2.6.13.  I don't want this bug released.

Robert Love


-
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: Inotify problem [was Re: 2.6.13-rc6-mm1]

[John McCutchan]

On Thu, 2005-08-25 at 14:18 +0200, Johannes Berg wrote:
> Hi,
> 
> > I have also observed another problem with inotify with dovecot - so I spoke 
> > with Johannes Berg who wrote the inotify code in dovecot.  He suggested I 
> > post 
> > here to LKML since his opinion is that this to be a kernel bug.
> 
> Allow me to jump in at this point. The small tool below triggers this
> problem for Reuben (confirmed via private mail) but works fine for me on
> 2.6.13-rc6.

On 2.6.13-rc7 the test program fails. It always fails when a wd == 1024.
If I skip inotify_rm_watch when wd == 1024, it will fail at wd == 2048.
It seems the idr layer has an aversion to multiples of 1024.

When I run your test program I get this a lot:

inotify_add_watch returned wd1 5
inotify_add_watch returned wd2 6
inotify_add_watch returned wd1 6
inotify_add_watch returned wd2 7

The pattern of 

add_watch wd1 = X
add_watch wd2 = X+1
rm_watch X
rm_watch X+1
add_watch wd1 = X+1
add_watch wd2 = X+2

Should never happen. We tell the idr layer to always give us something
bigger than the last wd we received.

Also, idr_get_new_above doesn't work all the time. Under 2.6.13-rc7, I
added this to inotify.c:359:

if (ret <= dev->last_wd) {
printk(KERN_INFO "idr_get_new_above returned <= dev->last_wd\n");
}

I get that message a lot. I know I have said this before (and was wrong)
but I think the idr layer is busted.

-- 
John McCutchan <[EMAIL PROTECTED]>
-
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: Inotify problem [was Re: 2.6.13-rc6-mm1]

[John McCutchan]

On Thu, 2005-08-25 at 22:07 +1200, Reuben Farrelly wrote:
> Hi,
> 
> I have also observed another problem with inotify with dovecot - so I spoke 
> with Johannes Berg who wrote the inotify code in dovecot.  He suggested I 
> post 
> here to LKML since his opinion is that this to be a kernel bug.
> 
> The problem I am observing is this, logged by dovecot after a period of time 
> when a client is connected:
> 
> dovecot: Aug 22 14:31:23 Error: IMAP(gilly): inotify_rm_watch() failed: 
> Invalid argument
> dovecot: Aug 22 14:31:23 Error: IMAP(gilly): inotify_rm_watch() failed: 
> Invalid argument
> dovecot: Aug 22 14:31:23 Error: IMAP(gilly): inotify_rm_watch() failed: 
> Invalid argument
> 
> Multiply that by about 1000 ;-)
> 
> Some debugging shows this:
> dovecot: Aug 25 19:31:22 Warning: IMAP(gilly): removing wd 1019 from inotify 
> fd 4
> dovecot: Aug 25 19:31:22 Warning: IMAP(gilly): removing wd 1018 from inotify 
> fd 4
> dovecot: Aug 25 19:31:22 Warning: IMAP(gilly): inotify_add_watch returned 1019
> dovecot: Aug 25 19:31:22 Warning: IMAP(gilly): inotify_add_watch returned 1020
> dovecot: Aug 25 19:31:23 Warning: IMAP(gilly): removing wd 1020 from inotify 
> fd 4
> dovecot: Aug 25 19:31:23 Warning: IMAP(gilly): removing wd 1019 from inotify 
> fd 4
> dovecot: Aug 25 19:31:24 Warning: IMAP(gilly): inotify_add_watch returned 1020



> dovecot: Aug 25 19:31:24 Warning: IMAP(gilly): inotify_add_watch returned 1021
> dovecot: Aug 25 19:31:24 Warning: IMAP(gilly): removing wd 1021 from inotify 
> fd 4
> dovecot: Aug 25 19:31:24 Warning: IMAP(gilly): removing wd 1020 from inotify 
> fd 4
> dovecot: Aug 25 19:31:25 Warning: IMAP(gilly): inotify_add_watch returned 1021
> dovecot: Aug 25 19:31:25 Warning: IMAP(gilly): inotify_add_watch returned 1022
> dovecot: Aug 25 19:31:25 Warning: IMAP(gilly): removing wd 1022 from inotify 
> fd 4
> dovecot: Aug 25 19:31:25 Warning: IMAP(gilly): removing wd 1021 from inotify 
> fd 4
> dovecot: Aug 25 19:31:26 Warning: IMAP(gilly): inotify_add_watch returned 1022
> dovecot: Aug 25 19:31:26 Warning: IMAP(gilly): inotify_add_watch returned 1023
> dovecot: Aug 25 19:31:26 Warning: IMAP(gilly): removing wd 1023 from inotify 
> fd 4
> dovecot: Aug 25 19:31:26 Warning: IMAP(gilly): removing wd 1022 from inotify 
> fd 4
> dovecot: Aug 25 19:31:27 Warning: IMAP(gilly): inotify_add_watch returned 1023
> dovecot: Aug 25 19:31:27 Warning: IMAP(gilly): inotify_add_watch returned 1024
> dovecot: Aug 25 19:31:27 Warning: IMAP(gilly): removing wd 1024 from inotify 
> fd 4
> dovecot: Aug 25 19:31:27 Error: IMAP(gilly): inotify_rm_watch() failed: 
> Invalid argument
> dovecot: Aug 25 19:31:27 Warning: IMAP(gilly): removing wd 1023 from inotify 
> fd 4
> dovecot: Aug 25 19:31:28 Warning: IMAP(gilly): inotify_add_watch returned 1024
> dovecot: Aug 25 19:31:28 Warning: IMAP(gilly): inotify_add_watch returned 1024
> 
> Note the incrementing wd value even though we are removing them as we go..
> 

What kernel are you running? The wd's should ALWAYS be incrementing, you
should never get the same wd as you did before. From your log, you are
getting the same wd (after you inotify_rm_watch it). I can reproduce
this bug on 2.6.13-rc7.

idr_get_new_above 

isn't returning something above.

Also, the idr layer seems to be breaking when we pass in 1024. I can
reproduce that on my 2.6.13-rc7 system as well.

> This is using latest CVS of dovecot code and with 2.6.12-rc6-mm(1|2) kernel.
> 
> Robert, John, what do you think?   Is this possibly related to the oops seen 
> in the log that I reported earlier?  (Which is still showing up 2-3 times per 
> day, btw)

There is definitely something broken here.

-- 
John McCutchan <[EMAIL PROTECTED]>
-
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: Inotify problem [was Re: 2.6.13-rc6-mm1]

[Johannes Berg]

Hi,

> I have also observed another problem with inotify with dovecot - so I spoke 
> with Johannes Berg who wrote the inotify code in dovecot.  He suggested I 
> post 
> here to LKML since his opinion is that this to be a kernel bug.

Allow me to jump in at this point. The small tool below triggers this
problem for Reuben (confirmed via private mail) but works fine for me on
2.6.13-rc6.

johannes

--begin test program--
/* Author: Johannes Berg <[EMAIL PROTECTED]>
 *
 * This is a small inotify test program that simply
 * repeatedly adds and removes watches.
 */

#include 
#include 
#include 

int main()
{
int fd;
int wd1, wd2;
int ret;

fd = inotify_init();

if (fd < 0)
perror("inotify_init");

printf("inotify_init returned fd %d\n", fd);

while (1) {
wd1 = inotify_add_watch(fd, "/tmp", IN_ALL_EVENTS);

if (wd1 < 0) {
perror("inotify_add_watch");
break;
}
printf("inotify_add_watch returned wd1 %d\n", wd1);

wd2 = inotify_add_watch(fd, "/", IN_ALL_EVENTS);

if (wd2 < 0) {
perror("inotify_add_watch");
break;
}
printf("inotify_add_watch returned wd2 %d\n", wd2);

ret = inotify_rm_watch(fd, wd1);
if (ret < 0) {
perror("inotify_rm_watch wd1");
break;
}
ret = inotify_rm_watch(fd, wd2);
if (ret < 0) {
perror("inotify_rm_watch wd2");
break;
}
}
}



signature.asc
Description: This is a digitally signed message part

Inotify problem [was Re: 2.6.13-rc6-mm1]

[Reuben Farrelly]

Hi,

On 22/08/2005 9:10 p.m., John McCutchan wrote:

On Sat, 2005-08-20 at 23:52 -0700, Andrew Morton wrote:

Reuben Farrelly <[EMAIL PROTECTED]> wrote:

Hi,

On 19/08/2005 11:37 a.m., Andrew Morton wrote:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc6/2.6.13-rc6-mm1/

- Lots of fixes, updates and cleanups all over the place.

- If you have the right debugging options set, this kernel will generate
  a storm of sleeping-in-atomic-code warnings at boot, from the scsi code.
  It is being worked on.


Changes since 2.6.13-rc5-mm1:

 linus.patch

Noted this in my log earlier today.

Is this inotify related?

Aug 21 08:33:04 tornado kernel: idr_remove called for id=2048 which is not 
allocated.

Aug 21 08:33:04 tornado kernel:  [] dump_stack+0x17/0x19
Aug 21 08:33:04 tornado kernel:  [] idr_remove_warning+0x1b/0x1d
Aug 21 08:33:04 tornado kernel:  [] sub_remove+0x88/0xea
Aug 21 08:33:04 tornado kernel:  [] idr_remove+0x1b/0x7f
Aug 21 08:33:04 tornado kernel:  [] remove_watch_no_event+0x7a/0x12e
Aug 21 08:33:04 tornado kernel:  [] inotify_release+0x8f/0x1af
Aug 21 08:33:04 tornado kernel:  [] __fput+0xaf/0x199
Aug 21 08:33:04 tornado kernel:  [] fput+0x22/0x3b
Aug 21 08:33:04 tornado kernel:  [] filp_close+0x41/0x67
Aug 21 08:33:04 tornado kernel:  [] sys_close+0x70/0x92
Aug 21 08:33:04 tornado kernel:  [] sysenter_past_esp+0x54/0x75
Aug 21 08:33:04 tornado kernel: idr_remove called for id=3072 which is not 
allocated.

Aug 21 08:33:05 tornado kernel:  [] dump_stack+0x17/0x19
Aug 21 08:33:05 tornado kernel:  [] idr_remove_warning+0x1b/0x1d
Aug 21 08:33:05 tornado kernel:  [] sub_remove+0x88/0xea
Aug 21 08:33:05 tornado kernel:  [] idr_remove+0x1b/0x7f
Aug 21 08:33:05 tornado kernel:  [] remove_watch_no_event+0x7a/0x12e
Aug 21 08:33:05 tornado kernel:  [] inotify_release+0x8f/0x1af
Aug 21 08:33:05 tornado kernel:  [] __fput+0xaf/0x199
Aug 21 08:33:05 tornado kernel:  [] fput+0x22/0x3b
Aug 21 08:33:05 tornado kernel:  [] filp_close+0x41/0x67
Aug 21 08:33:05 tornado kernel:  [] sys_close+0x70/0x92
Aug 21 08:33:05 tornado kernel:  [] sysenter_past_esp+0x54/0x75

This would have been triggered by using dovecot IMAP which is configured to 
use inotify on Maildir.

I'm also seeing some userspace errors logged for dovecot:

"Aug 21 04:17:22 Error: IMAP(reuben): inotify_rm_watch() failed: Invalid 
argument"

I'll deal with those with the guy who wrote the inotify code in dovecot.

I'm not so sure userspace should be able or need to cause the kernel to dump 
stack traces like that though?



Yes, the stack dumps would appear to be due to an inotify bug.

The message from dovecot is allegedly due to dovecot passing in a file
descriptor which was not obtained from the inotify_init() syscall.  But
until we know what caused those stack dumps we cannot definitely say
whether dovecot is at fault.



Inotify has a check on both add and rm watch syscalls:

/* verify that this is indeed an inotify instance */
if (unlikely(filp->f_op != &inotify_fops)) {
ret = -EINVAL;
goto out;
}

This is crashing in inotify_release, which is called on close of the
inotify instance. So this fd must be from an inotify instance right?

I looked at the dovecot code, it looks fine wrt inotify. Long shot, but
the close-on-exec flag is set. Could this be tripping anything up?


I have also observed another problem with inotify with dovecot - so I spoke 
with Johannes Berg who wrote the inotify code in dovecot.  He suggested I post 
here to LKML since his opinion is that this to be a kernel bug.


The problem I am observing is this, logged by dovecot after a period of time 
when a client is connected:


dovecot: Aug 22 14:31:23 Error: IMAP(gilly): inotify_rm_watch() failed: 
Invalid argument
dovecot: Aug 22 14:31:23 Error: IMAP(gilly): inotify_rm_watch() failed: 
Invalid argument
dovecot: Aug 22 14:31:23 Error: IMAP(gilly): inotify_rm_watch() failed: 
Invalid argument


Multiply that by about 1000 ;-)

Some debugging shows this:
dovecot: Aug 25 19:31:22 Warning: IMAP(gilly): removing wd 1019 from inotify fd 
4
dovecot: Aug 25 19:31:22 Warning: IMAP(gilly): removing wd 1018 from inotify fd 
4
dovecot: Aug 25 19:31:22 Warning: IMAP(gilly): inotify_add_watch returned 1019
dovecot: Aug 25 19:31:22 Warning: IMAP(gilly): inotify_add_watch returned 1020
dovecot: Aug 25 19:31:23 Warning: IMAP(gilly): removing wd 1020 from inotify fd 
4
dovecot: Aug 25 19:31:23 Warning: IMAP(gilly): removing wd 1019 from inotify fd 
4
dovecot: Aug 25 19:31:24 Warning: IMAP(gilly): inotify_add_watch returned 1020
dovecot: Aug 25 19:31:24 Warning: IMAP(gilly): inotify_add_watch returned 1021
dovecot: Aug 25 19:31:24 Warning: IMAP(gilly): removing wd 1021 from inotify fd 
4
dovecot: Aug 25 19:31:24 Warning: IMAP(gilly): removing wd 1020 from inotify fd 
4
dovecot: Aug 25 19:31:25 Warning: IMAP(gilly): inotify_add_watch returned 1021
dovecot: Aug 25 19:31:25 Warning: IMAP(gilly): inotify_a

Re: 2.6.13-rc6-mm1

[Rogério Brito]

Hi.

Unfortunately, it seems that current kernels (including vanilla -rc
kernels) don't compile correctly on ppc if I have APM emulation enabled,
but PMU disabled (only CUDA enabled).

Here is what I get from a compilation try:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
debian:~/kernel/linux# make vmlinux
  CHK include/linux/version.h
make[1]: `arch/ppc/kernel/asm-offsets.s' is up to date.
  CHK include/linux/compile.h
  CHK usr/initramfs_list
  CC  sound/oss/dmasound/dmasound_awacs.o
sound/oss/dmasound/dmasound_awacs.c:262: warning: 'struct pmu_sleep_notifier' 
declared inside parameter list
sound/oss/dmasound/dmasound_awacs.c:262: warning: its scope is only this 
definition or declaration, which is probably not what you want
sound/oss/dmasound/dmasound_awacs.c:263: error: variable 'awacs_sleep_notifier' 
has initializer but incomplete type
sound/oss/dmasound/dmasound_awacs.c:264: warning: excess elements in struct 
initializer
sound/oss/dmasound/dmasound_awacs.c:264: warning: (near initialization for 
'awacs_sleep_notifier')
sound/oss/dmasound/dmasound_awacs.c:264: error: 'SLEEP_LEVEL_SOUND' undeclared 
here (not in a function)
sound/oss/dmasound/dmasound_awacs.c:264: warning: excess elements in struct 
initializer
sound/oss/dmasound/dmasound_awacs.c:264: warning: (near initialization for 
'awacs_sleep_notifier')
sound/oss/dmasound/dmasound_awacs.c:1424: error: conflicting types for 
'awacs_sleep_notify'
sound/oss/dmasound/dmasound_awacs.c:262: error: previous declaration of 
'awacs_sleep_notify' was here
sound/oss/dmasound/dmasound_awacs.c: In function 'awacs_sleep_notify':
sound/oss/dmasound/dmasound_awacs.c:1428: error: 'PBOOK_SLEEP_NOW' undeclared 
(first use in this function)
sound/oss/dmasound/dmasound_awacs.c:1428: error: (Each undeclared identifier is 
reported only once
sound/oss/dmasound/dmasound_awacs.c:1428: error: for each function it appears 
in.)
sound/oss/dmasound/dmasound_awacs.c:1481: error: 'PBOOK_WAKE' undeclared (first 
use in this function)
sound/oss/dmasound/dmasound_awacs.c:1552: error: 'PBOOK_SLEEP_OK' undeclared 
(first use in this function)
sound/oss/dmasound/dmasound_awacs.c: In function 'dmasound_awacs_init':
sound/oss/dmasound/dmasound_awacs.c:3057: warning: implicit declaration of 
function 'pmu_register_sleep_notifier'
make[3]: *** [sound/oss/dmasound/dmasound_awacs.o] Error 1
make[2]: *** [sound/oss/dmasound] Error 2
make[1]: *** [sound/oss] Error 2
make: *** [sound] Error 2
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

If I enable CONFIG_ADB_PMU, then it compiles fine. :-(


Thanks in advance for any help, Rogério.

-- 
Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/
-
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.13-rc6-mm1

[Andrew Morton]

Rogério Brito <[EMAIL PROTECTED]> wrote:
>
> Unfortunately, it seems that current kernels (including vanilla -rc
>  kernels) don't compile correctly on ppc if I have APM emulation enabled,
>  but PMU disabled (only CUDA enabled).
> 
>  Here is what I get from a compilation try:
> 
>  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>  debian:~/kernel/linux# make vmlinux
>CHK include/linux/version.h
>  make[1]: `arch/ppc/kernel/asm-offsets.s' is up to date.
>CHK include/linux/compile.h
>CHK usr/initramfs_list
>CC  sound/oss/dmasound/dmasound_awacs.o
>  sound/oss/dmasound/dmasound_awacs.c:262: warning: 'struct 
> pmu_sleep_notifier' declared inside parameter list
>  sound/oss/dmasound/dmasound_awacs.c:262: warning: its scope is only this 
> definition or declaration, which is probably not what you want
>  sound/oss/dmasound/dmasound_awacs.c:263: error: variable 
> 'awacs_sleep_notifier' has initializer but incomplete type
>  sound/oss/dmasound/dmasound_awacs.c:264: warning: excess elements in struct 
> initializer
>  sound/oss/dmasound/dmasound_awacs.c:264: warning: (near initialization for 
> 'awacs_sleep_notifier')
>  sound/oss/dmasound/dmasound_awacs.c:264: error: 'SLEEP_LEVEL_SOUND' 
> undeclared here (not in a function)
>  sound/oss/dmasound/dmasound_awacs.c:264: warning: excess elements in struct 
> initializer
>  sound/oss/dmasound/dmasound_awacs.c:264: warning: (near initialization for 
> 'awacs_sleep_notifier')
>  sound/oss/dmasound/dmasound_awacs.c:1424: error: conflicting types for 
> 'awacs_sleep_notify'
>  sound/oss/dmasound/dmasound_awacs.c:262: error: previous declaration of 
> 'awacs_sleep_notify' was here
>  sound/oss/dmasound/dmasound_awacs.c: In function 'awacs_sleep_notify':
>  sound/oss/dmasound/dmasound_awacs.c:1428: error: 'PBOOK_SLEEP_NOW' 
> undeclared (first use in this function)

Could you send the .config please?
-
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.13-rc6-mm1

[Rogério Brito]

On Aug 21 2005, Andrew Morton wrote:
> Rogério Brito <[EMAIL PROTECTED]> wrote:
> > Unfortunately, it seems that current kernels (including vanilla -rc
> > kernels) don't compile correctly on ppc if I have APM emulation
> > enabled, but PMU disabled (only CUDA enabled).
> > 
> > Here is what I get from a compilation try:
(...)
> 
> Could you send the .config please?

Sure. I is attached to this message. Please let me know if I can help
with any other information.


Thanks, Rogério Brito.

-- 
Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.13-rc6-mm1-4.ow
# Sun Aug 21 07:26:29 2005
#
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_PPC=y
CONFIG_PPC32=y
CONFIG_GENERIC_NVRAM=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0

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

#
# Processor
#
CONFIG_6xx=y
# CONFIG_40x is not set
# CONFIG_44x is not set
# CONFIG_POWER3 is not set
# CONFIG_POWER4 is not set
# CONFIG_8xx is not set
# CONFIG_E200 is not set
# CONFIG_E500 is not set
CONFIG_PPC_FPU=y
# CONFIG_ALTIVEC is not set
# CONFIG_TAU is not set
# CONFIG_KEXEC is not set
# CONFIG_CPU_FREQ is not set
# CONFIG_PPC601_SYNC_FIX is not set
CONFIG_PM=y
CONFIG_PPC_STD_MMU=y

#
# Performance-monitoring counters support
#
# CONFIG_PERFCTR is not set

#
# Platform options
#
CONFIG_PPC_MULTIPLATFORM=y
# CONFIG_APUS is not set
# CONFIG_KATANA is not set
# CONFIG_WILLOW is not set
# CONFIG_CPCI690 is not set
# CONFIG_POWERPMC250 is not set
# CONFIG_CHESTNUT is not set
# CONFIG_SPRUCE is not set
# CONFIG_HDPU is not set
# CONFIG_EV64260 is not set
# CONFIG_LOPEC is not set
# CONFIG_MVME5100 is not set
# CONFIG_PPLUS is not set
# CONFIG_PRPMC750 is not set
# CONFIG_PRPMC800 is not set
# CONFIG_SANDPOINT is not set
# CONFIG_RADSTONE_PPC7D is not set
# CONFIG_PAL4 is not set
# CONFIG_GEMINI is not set
# CONFIG_EST8260 is not set
# CONFIG_SBC82xx is not set
# CONFIG_SBS8260 is not set
# CONFIG_RPX8260 is not set
# CONFIG_TQM8260 is not set
# CONFIG_ADS8272 is not set
# CONFIG_PQ2FADS is not set
# CONFIG_LITE5200 is not set
# CONFIG_MPC834x_SYS is not set
CONFIG_PPC_CHRP=y
CONFIG_PPC_PMAC=y
CONFIG_PPC_PREP=y
CONFIG_PPC_OF=y
CONFIG_PPCBUG_NVRAM=y
# CONFIG_SMP is not set
# CONFIG_HIGHMEM is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
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_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_PROC_DEVICETREE=y
# CONFIG_PREP_RESIDUAL is not set
# CONFIG_CMDLINE_BOOL is not set
# CONFIG_PM_DEBUG is not set
# CONFIG_SOFTWARE_SUSPEND is not set
CONFIG_SECCOMP=y
CONFIG_ISA_DMA_API=y

#
# Bus options
#
# CONFIG_ISA is not set
CONFIG_GENERIC_ISA_DMA=y
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCI_LEGACY_PROC is not set
# CONFIG_PCI_DEBUG is not set

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# Advanced setup
#
# CONFIG_ADVANCED_OPTIONS is not set

#
# Default settings for advanced configuration options are used
#
CONFIG_HIGHMEM_START=0xfe00
CONFIG_LOWMEM_SIZE=0x3000
CONFIG_KERNEL_START=0xc000
CONFIG_TASK_SIZE=0x8000
CONFIG_BOOT_LOAD=0x0080

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
CONFIG_NET_KEY=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_I

Re: 2.6.13-rc6-mm1

[Benoit Boissinot]

On Sun, Aug 21, 2005 at 06:34:48PM -0400, Jon Smirl wrote:
> This should fix it, but I'm not on a machine where I can test it. Can
> you give it a try and let me know?
> 

it works ok.
But there is still at least one problem: if ops->store returns an error,
then there will be a substraction and the write will loop (i could do it
with a store wich returned EINVAL and a 22 length string).

I don't know if you can put a '\0' at buffer->page[count] if
count == PAGE_SIZE.

Moreover, i think it is more correct to add only the leading
whitespace from the count because if the ops->store doesn't read
everything it will do something weird:

For example, if we have ' 123' and ops->store read only one char,
then the function will return 7 (1 leading + 4 trailing + 1 read).  For
the next call the buffer will be filled only by spaces which is
incorrect (it should be '23').

> diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
> --- a/fs/sysfs/file.c
> +++ b/fs/sysfs/file.c
> @@ -6,6 +6,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -207,8 +208,28 @@ flush_write_buffer(struct dentry * dentr
>   struct attribute * attr = to_attr(dentry);
>   struct kobject * kobj = to_kobj(dentry->d_parent);
>   struct sysfs_ops * ops = buffer->ops;
> + int ws_count = count;
> + char *x;
>  
> - return ops->store(kobj,attr,buffer->page,count);
> + /* locate trailing white space */
> + while ((count > 0) && isspace(buffer->page[count - 1]))
> + count--;
> +
> + /* locate leading white space */
> + x = buffer->page;
> + if (count > 0) {
> + while (isspace(*x))
> + x++;
> + count -= (x - buffer->page);
> + }
> + /* terminate the string */
> + x[count] = '\0';
 what if count == PAGE_SIZE ?
> + ws_count -= count;
> +
> + if (count != 0)
> + count = ops->store(kobj, attr, x, count);
> +
> + return count + ws_count;
return (count < 0) ? count : count + ws_count;
>  }
>  
>  
-- 
powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS
-
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.13-rc6-mm1

[John McCutchan]

On Sat, 2005-08-20 at 23:52 -0700, Andrew Morton wrote:
> Reuben Farrelly <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> > 
> > On 19/08/2005 11:37 a.m., Andrew Morton wrote:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc6/2.6.13-rc6-mm1/
> > > 
> > > - Lots of fixes, updates and cleanups all over the place.
> > > 
> > > - If you have the right debugging options set, this kernel will generate
> > >   a storm of sleeping-in-atomic-code warnings at boot, from the scsi code.
> > >   It is being worked on.
> > > 
> > > 
> > > Changes since 2.6.13-rc5-mm1:
> > > 
> > >  linus.patch
> > 
> > Noted this in my log earlier today.
> > 
> > Is this inotify related?
> > 
> > Aug 21 08:33:04 tornado kernel: idr_remove called for id=2048 which is not 
> > allocated.
> > Aug 21 08:33:04 tornado kernel:  [] dump_stack+0x17/0x19
> > Aug 21 08:33:04 tornado kernel:  [] idr_remove_warning+0x1b/0x1d
> > Aug 21 08:33:04 tornado kernel:  [] sub_remove+0x88/0xea
> > Aug 21 08:33:04 tornado kernel:  [] idr_remove+0x1b/0x7f
> > Aug 21 08:33:04 tornado kernel:  [] 
> > remove_watch_no_event+0x7a/0x12e
> > Aug 21 08:33:04 tornado kernel:  [] inotify_release+0x8f/0x1af
> > Aug 21 08:33:04 tornado kernel:  [] __fput+0xaf/0x199
> > Aug 21 08:33:04 tornado kernel:  [] fput+0x22/0x3b
> > Aug 21 08:33:04 tornado kernel:  [] filp_close+0x41/0x67
> > Aug 21 08:33:04 tornado kernel:  [] sys_close+0x70/0x92
> > Aug 21 08:33:04 tornado kernel:  [] sysenter_past_esp+0x54/0x75
> > Aug 21 08:33:04 tornado kernel: idr_remove called for id=3072 which is not 
> > allocated.
> > Aug 21 08:33:05 tornado kernel:  [] dump_stack+0x17/0x19
> > Aug 21 08:33:05 tornado kernel:  [] idr_remove_warning+0x1b/0x1d
> > Aug 21 08:33:05 tornado kernel:  [] sub_remove+0x88/0xea
> > Aug 21 08:33:05 tornado kernel:  [] idr_remove+0x1b/0x7f
> > Aug 21 08:33:05 tornado kernel:  [] 
> > remove_watch_no_event+0x7a/0x12e
> > Aug 21 08:33:05 tornado kernel:  [] inotify_release+0x8f/0x1af
> > Aug 21 08:33:05 tornado kernel:  [] __fput+0xaf/0x199
> > Aug 21 08:33:05 tornado kernel:  [] fput+0x22/0x3b
> > Aug 21 08:33:05 tornado kernel:  [] filp_close+0x41/0x67
> > Aug 21 08:33:05 tornado kernel:  [] sys_close+0x70/0x92
> > Aug 21 08:33:05 tornado kernel:  [] sysenter_past_esp+0x54/0x75
> > 
> > This would have been triggered by using dovecot IMAP which is configured to 
> > use inotify on Maildir.
> > I'm also seeing some userspace errors logged for dovecot:
> > 
> > "Aug 21 04:17:22 Error: IMAP(reuben): inotify_rm_watch() failed: Invalid 
> > argument"
> > 
> > I'll deal with those with the guy who wrote the inotify code in dovecot.
> > 
> > I'm not so sure userspace should be able or need to cause the kernel to 
> > dump 
> > stack traces like that though?
> > 
> 
> Yes, the stack dumps would appear to be due to an inotify bug.
> 
> The message from dovecot is allegedly due to dovecot passing in a file
> descriptor which was not obtained from the inotify_init() syscall.  But
> until we know what caused those stack dumps we cannot definitely say
> whether dovecot is at fault.
> 

Inotify has a check on both add and rm watch syscalls:

/* verify that this is indeed an inotify instance */
if (unlikely(filp->f_op != &inotify_fops)) {
ret = -EINVAL;
goto out;
}

This is crashing in inotify_release, which is called on close of the
inotify instance. So this fd must be from an inotify instance right?

I looked at the dovecot code, it looks fine wrt inotify. Long shot, but
the close-on-exec flag is set. Could this be tripping anything up?

-- 
John McCutchan <[EMAIL PROTECTED]>
-
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.13-rc6-mm1

[Jon Smirl]

On 8/22/05, Benoit Boissinot <[EMAIL PROTECTED]> wrote:
> On Sun, Aug 21, 2005 at 06:34:48PM -0400, Jon Smirl wrote:
> > This should fix it, but I'm not on a machine where I can test it. Can
> > you give it a try and let me know?
> >
> 
> it works ok.
> But there is still at least one problem: if ops->store returns an error,
> then there will be a substraction and the write will loop (i could do it
> with a store wich returned EINVAL and a 22 length string).
> 
> I don't know if you can put a '\0' at buffer->page[count] if
> count == PAGE_SIZE.
> 
> Moreover, i think it is more correct to add only the leading
> whitespace from the count because if the ops->store doesn't read
> everything it will do something weird:
> 
> For example, if we have ' 123' and ops->store read only one char,
> then the function will return 7 (1 leading + 4 trailing + 1 read).  For
> the next call the buffer will be filled only by spaces which is
> incorrect (it should be '23').

The attached version tries to fix these issues. I am still not
somewhere where I can test, so please check it out.

-- 
Jon Smirl
[EMAIL PROTECTED]
diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -207,8 +208,41 @@ flush_write_buffer(struct dentry * dentr
 	struct attribute * attr = to_attr(dentry);
 	struct kobject * kobj = to_kobj(dentry->d_parent);
 	struct sysfs_ops * ops = buffer->ops;
+	size_t ws_count = count, leading = 0;
+	int ret = 0;
+	char *x;
 
-	return ops->store(kobj,attr,buffer->page,count);
+	/* locate trailing white space */
+	while ((ws_count > 0) && isspace(buffer->page[ws_count - 1]))
+		ws_count--;
+	if (ws_count == 0)
+		return count;
+
+	/* locate leading white space */
+	x = buffer->page;
+	while (isspace(*x))
+		x++;
+	leading = x - buffer->page;
+	ws_count -= leading;
+
+	/* interface is still ambigous about this */
+	/* string is both passed by length and terminated */
+	if (ws_count != PAGE_SIZE)
+		x[ws_count] = '\0';
+
+	ret = ops->store(kobj, attr, x, ws_count);
+
+	/* is it an error? */
+	if (ret < 0) 
+		return ret;
+
+	/* the whole string was consumed */
+	if (ret == ws_count)
+		return count;
+
+	/* only part of the string was consumed */
+	/* return count can not include trailing space */
+	return leading + ret;
 }
 
 

Re: 2.6.13-rc6-mm1

[Benoit Boissinot]

On Mon, Aug 22, 2005 at 12:44:01PM -0400, Jon Smirl wrote:
> On 8/22/05, Benoit Boissinot <[EMAIL PROTECTED]> wrote:
> > On Sun, Aug 21, 2005 at 06:34:48PM -0400, Jon Smirl wrote:
> > > This should fix it, but I'm not on a machine where I can test it. Can
> > > you give it a try and let me know?
> > >
> > 
> > it works ok.
> > But there is still at least one problem: if ops->store returns an error,
> > then there will be a substraction and the write will loop (i could do it
> > with a store wich returned EINVAL and a 22 length string).
> > 
> > I don't know if you can put a '\0' at buffer->page[count] if
> > count == PAGE_SIZE.
> > 
> > Moreover, i think it is more correct to add only the leading
> > whitespace from the count because if the ops->store doesn't read
> > everything it will do something weird:
> > 
> > For example, if we have ' 123' and ops->store read only one char,
> > then the function will return 7 (1 leading + 4 trailing + 1 read).  For
> > the next call the buffer will be filled only by spaces which is
> > incorrect (it should be '23').
> 
> The attached version tries to fix these issues. I am still not
> somewhere where I can test, so please check it out.
> 

Yes it works fine, thanks.

Benoit Boissinot

-- 
powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS
-
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.13-rc6-mm1

[Jon Smirl]

This should fix it, but I'm not on a machine where I can test it. Can
you give it a try and let me know?

On 8/21/05, Benoit Boissinot <[EMAIL PROTECTED]> wrote:
> - Forwarded message from Benoit Boissinot <[EMAIL PROTECTED]> -
> sorry, i forgot to reply all...
> 
> From: Benoit Boissinot <[EMAIL PROTECTED]>
> To: Jon Smirl <[EMAIL PROTECTED]>
> Subject: Re: 2.6.13-rc6-mm1
> User-Agent: Mutt/1.5.10i
> 
> On Sun, Aug 21, 2005 at 06:11:57PM -0400, Jon Smirl wrote:
> > On 8/21/05, Benoit Boissinot <[EMAIL PROTECTED]> wrote:
> > > On Sun, Aug 21, 2005 at 01:40:31PM -0400, Jon Smirl wrote:
> > > > On 8/21/05, Benoit Boissinot <[EMAIL PROTECTED]> wrote:
> > > > [snip]
> > > >
> > > > Somewhere there is a mistake in the white space processing code of the
> > > > firmware driver. Before this patch we had inconsistent handling of
> > > > whitespace and sysfs attributes. This patch forces it to be consistent
> > > > and will shake out all of the places in the drivers where it is
> > > > handled wrong. Sysfs attributes are now stripped of leading and
> > > > trailing white space before being handed to the device driver.
> > >
> > > ok, i found it. If i do echo 1, it will read '1\n', will
> > > remove the '\n' and send '1' to ops->store.
> > > Then it will re-read '\n' and send '' to ops->store.
> > > And it will loop...
> >
> > Look at the length being passed in, isn't it set to zero for the second 
> > case?
> >
> yes, it is set to zero, but the '\n' will be stripped and stay in the buffer.
> Since flush_write_buffer returns 0, ppos will not be incremented and we
> have an endless loop.
> 
> --
> powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS
> 
> - End forwarded message -
> 
> --
> powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS
> -
> 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/
> 


-- 
Jon Smirl
[EMAIL PROTECTED]
diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -207,8 +208,28 @@ flush_write_buffer(struct dentry * dentr
 	struct attribute * attr = to_attr(dentry);
 	struct kobject * kobj = to_kobj(dentry->d_parent);
 	struct sysfs_ops * ops = buffer->ops;
+	int ws_count = count;
+	char *x;
 
-	return ops->store(kobj,attr,buffer->page,count);
+	/* locate trailing white space */
+	while ((count > 0) && isspace(buffer->page[count - 1]))
+		count--;
+
+	/* locate leading white space */
+	x = buffer->page;
+	if (count > 0) {
+		while (isspace(*x))
+			x++;
+		count -= (x - buffer->page);
+	}
+	/* terminate the string */
+	x[count] = '\0';
+	ws_count -= count;
+
+	if (count != 0)
+		count = ops->store(kobj, attr, x, count);
+
+	return count + ws_count;
 }
 
 

Re: 2.6.13-rc6-mm1

[Benoit Boissinot]

- Forwarded message from Benoit Boissinot <[EMAIL PROTECTED]> -
sorry, i forgot to reply all...

From: Benoit Boissinot <[EMAIL PROTECTED]>
To: Jon Smirl <[EMAIL PROTECTED]>
Subject: Re: 2.6.13-rc6-mm1
User-Agent: Mutt/1.5.10i

On Sun, Aug 21, 2005 at 06:11:57PM -0400, Jon Smirl wrote:
> On 8/21/05, Benoit Boissinot <[EMAIL PROTECTED]> wrote:
> > On Sun, Aug 21, 2005 at 01:40:31PM -0400, Jon Smirl wrote:
> > > On 8/21/05, Benoit Boissinot <[EMAIL PROTECTED]> wrote:
> > > [snip]
> > >
> > > Somewhere there is a mistake in the white space processing code of the
> > > firmware driver. Before this patch we had inconsistent handling of
> > > whitespace and sysfs attributes. This patch forces it to be consistent
> > > and will shake out all of the places in the drivers where it is
> > > handled wrong. Sysfs attributes are now stripped of leading and
> > > trailing white space before being handed to the device driver.
> > 
> > ok, i found it. If i do echo 1, it will read '1\n', will
> > remove the '\n' and send '1' to ops->store.
> > Then it will re-read '\n' and send '' to ops->store.
> > And it will loop...
> 
> Look at the length being passed in, isn't it set to zero for the second case?
> 
yes, it is set to zero, but the '\n' will be stripped and stay in the buffer.
Since flush_write_buffer returns 0, ppos will not be incremented and we
have an endless loop.

-- 
powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS

- End forwarded message -

-- 
powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS
-
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.13-rc6-mm1

[Jon Smirl]

On 8/21/05, Benoit Boissinot <[EMAIL PROTECTED]> wrote:
> On Sun, Aug 21, 2005 at 01:40:31PM -0400, Jon Smirl wrote:
> > On 8/21/05, Benoit Boissinot <[EMAIL PROTECTED]> wrote:
> > > On 8/19/05, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > >
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc6/2.6.13-rc6-mm1/
> > > >
> > > > - Lots of fixes, updates and cleanups all over the place.
> > > >
> > > > - If you have the right debugging options set, this kernel will generate
> > > >   a storm of sleeping-in-atomic-code warnings at boot, from the scsi 
> > > > code.
> > > >   It is being worked on.
> > > >
> > > >
> > > > Changes since 2.6.13-rc5-mm1:
> > > > [...]
> > > > +gregkh-driver-sysfs-strip_leading_trailing_whitespace.patch
> > > > [...]
> > >
> > >
> > > it broke loading of firmware for me.(dmesg was flooded with
> > > "firmware_loading_store:  unexpected value (0)")
> > >
> > > firmware.agent uses echo so there is a trailing newline. If i changes
> > > firmware.agent to uses echo -n it works correctly.
> > >
> > > Is this a bug or the correct behaviour ?
> >
> > Somewhere there is a mistake in the white space processing code of the
> > firmware driver. Before this patch we had inconsistent handling of
> > whitespace and sysfs attributes. This patch forces it to be consistent
> > and will shake out all of the places in the drivers where it is
> > handled wrong. Sysfs attributes are now stripped of leading and
> > trailing white space before being handed to the device driver.
> 
> ok, i found it. If i do echo 1, it will read '1\n', will
> remove the '\n' and send '1' to ops->store.
> Then it will re-read '\n' and send '' to ops->store.
> And it will loop...

Look at the length being passed in, isn't it set to zero for the second case?

> 
> Maybe sysfs should return the old count instead of ops->store ?
> >
> > Fbdev sysfs attributes are also broken for white space handling and
> > need to be fixed. Overall the patch should be correct and it is the
> > drivers that are broken.
> >
> Regards,
> 
> Benoit Boissinot
> 
> --
> powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS
> 


-- 
Jon Smirl
[EMAIL PROTECTED]
-
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.13-rc6-mm1

[Benoit Boissinot]

On 8/19/05, Andrew Morton <[EMAIL PROTECTED]> wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc6/2.6.13-rc6-mm1/
> 
> - Lots of fixes, updates and cleanups all over the place.
> 
> - If you have the right debugging options set, this kernel will generate
>   a storm of sleeping-in-atomic-code warnings at boot, from the scsi code.
>   It is being worked on.
> 
> 
> Changes since 2.6.13-rc5-mm1:
> [...]
> +gregkh-driver-sysfs-strip_leading_trailing_whitespace.patch
> [...]


it broke loading of firmware for me.(dmesg was flooded with
"firmware_loading_store:  unexpected value (0)")

firmware.agent uses echo so there is a trailing newline. If i changes
firmware.agent to uses echo -n it works correctly.

Is this a bug or the correct behaviour ?

regards,

Benoit
-
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.13-rc6-mm1

[Benoit Boissinot]

On Sun, Aug 21, 2005 at 01:40:31PM -0400, Jon Smirl wrote:
> On 8/21/05, Benoit Boissinot <[EMAIL PROTECTED]> wrote:
> > On 8/19/05, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc6/2.6.13-rc6-mm1/
> > >
> > > - Lots of fixes, updates and cleanups all over the place.
> > >
> > > - If you have the right debugging options set, this kernel will generate
> > >   a storm of sleeping-in-atomic-code warnings at boot, from the scsi code.
> > >   It is being worked on.
> > >
> > >
> > > Changes since 2.6.13-rc5-mm1:
> > > [...]
> > > +gregkh-driver-sysfs-strip_leading_trailing_whitespace.patch
> > > [...]
> > 
> > 
> > it broke loading of firmware for me.(dmesg was flooded with
> > "firmware_loading_store:  unexpected value (0)")
> > 
> > firmware.agent uses echo so there is a trailing newline. If i changes
> > firmware.agent to uses echo -n it works correctly.
> > 
> > Is this a bug or the correct behaviour ?
> 
> Somewhere there is a mistake in the white space processing code of the
> firmware driver. Before this patch we had inconsistent handling of
> whitespace and sysfs attributes. This patch forces it to be consistent
> and will shake out all of the places in the drivers where it is
> handled wrong. Sysfs attributes are now stripped of leading and
> trailing white space before being handed to the device driver.

ok, i found it. If i do echo 1, it will read '1\n', will
remove the '\n' and send '1' to ops->store.
Then it will re-read '\n' and send '' to ops->store.
And it will loop...

Maybe sysfs should return the old count instead of ops->store ?
> 
> Fbdev sysfs attributes are also broken for white space handling and
> need to be fixed. Overall the patch should be correct and it is the
> drivers that are broken.
> 
Regards,

Benoit Boissinot

-- 
powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS
-
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.13-rc6-mm1

[Jon Smirl]

On 8/21/05, Benoit Boissinot <[EMAIL PROTECTED]> wrote:
> On 8/19/05, Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc6/2.6.13-rc6-mm1/
> >
> > - Lots of fixes, updates and cleanups all over the place.
> >
> > - If you have the right debugging options set, this kernel will generate
> >   a storm of sleeping-in-atomic-code warnings at boot, from the scsi code.
> >   It is being worked on.
> >
> >
> > Changes since 2.6.13-rc5-mm1:
> > [...]
> > +gregkh-driver-sysfs-strip_leading_trailing_whitespace.patch
> > [...]
> 
> 
> it broke loading of firmware for me.(dmesg was flooded with
> "firmware_loading_store:  unexpected value (0)")
> 
> firmware.agent uses echo so there is a trailing newline. If i changes
> firmware.agent to uses echo -n it works correctly.
> 
> Is this a bug or the correct behaviour ?

Somewhere there is a mistake in the white space processing code of the
firmware driver. Before this patch we had inconsistent handling of
whitespace and sysfs attributes. This patch forces it to be consistent
and will shake out all of the places in the drivers where it is
handled wrong. Sysfs attributes are now stripped of leading and
trailing white space before being handed to the device driver.

Fbdev sysfs attributes are also broken for white space handling and
need to be fixed. Overall the patch should be correct and it is the
drivers that are broken.

-- 
Jon Smirl
[EMAIL PROTECTED]
-
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.13-rc6-mm1

[Martin J. Bligh]

> -scheduler-cache-hot-autodetect.patch
> 
>  Mabe Martin's machine crash

That machine now boots again with this -mm release. Darren and/or I
will continue trying to figure out what went wrong with this.
 
M.
-
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.13-rc6-mm1

[Andrew Morton]

Reuben Farrelly <[EMAIL PROTECTED]> wrote:
>
> Hi,
> 
> On 19/08/2005 11:37 a.m., Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc6/2.6.13-rc6-mm1/
> > 
> > - Lots of fixes, updates and cleanups all over the place.
> > 
> > - If you have the right debugging options set, this kernel will generate
> >   a storm of sleeping-in-atomic-code warnings at boot, from the scsi code.
> >   It is being worked on.
> > 
> > 
> > Changes since 2.6.13-rc5-mm1:
> > 
> >  linus.patch
> 
> Noted this in my log earlier today.
> 
> Is this inotify related?
> 
> Aug 21 08:33:04 tornado kernel: idr_remove called for id=2048 which is not 
> allocated.
> Aug 21 08:33:04 tornado kernel:  [] dump_stack+0x17/0x19
> Aug 21 08:33:04 tornado kernel:  [] idr_remove_warning+0x1b/0x1d
> Aug 21 08:33:04 tornado kernel:  [] sub_remove+0x88/0xea
> Aug 21 08:33:04 tornado kernel:  [] idr_remove+0x1b/0x7f
> Aug 21 08:33:04 tornado kernel:  [] remove_watch_no_event+0x7a/0x12e
> Aug 21 08:33:04 tornado kernel:  [] inotify_release+0x8f/0x1af
> Aug 21 08:33:04 tornado kernel:  [] __fput+0xaf/0x199
> Aug 21 08:33:04 tornado kernel:  [] fput+0x22/0x3b
> Aug 21 08:33:04 tornado kernel:  [] filp_close+0x41/0x67
> Aug 21 08:33:04 tornado kernel:  [] sys_close+0x70/0x92
> Aug 21 08:33:04 tornado kernel:  [] sysenter_past_esp+0x54/0x75
> Aug 21 08:33:04 tornado kernel: idr_remove called for id=3072 which is not 
> allocated.
> Aug 21 08:33:05 tornado kernel:  [] dump_stack+0x17/0x19
> Aug 21 08:33:05 tornado kernel:  [] idr_remove_warning+0x1b/0x1d
> Aug 21 08:33:05 tornado kernel:  [] sub_remove+0x88/0xea
> Aug 21 08:33:05 tornado kernel:  [] idr_remove+0x1b/0x7f
> Aug 21 08:33:05 tornado kernel:  [] remove_watch_no_event+0x7a/0x12e
> Aug 21 08:33:05 tornado kernel:  [] inotify_release+0x8f/0x1af
> Aug 21 08:33:05 tornado kernel:  [] __fput+0xaf/0x199
> Aug 21 08:33:05 tornado kernel:  [] fput+0x22/0x3b
> Aug 21 08:33:05 tornado kernel:  [] filp_close+0x41/0x67
> Aug 21 08:33:05 tornado kernel:  [] sys_close+0x70/0x92
> Aug 21 08:33:05 tornado kernel:  [] sysenter_past_esp+0x54/0x75
> 
> This would have been triggered by using dovecot IMAP which is configured to 
> use inotify on Maildir.
> I'm also seeing some userspace errors logged for dovecot:
> 
> "Aug 21 04:17:22 Error: IMAP(reuben): inotify_rm_watch() failed: Invalid 
> argument"
> 
> I'll deal with those with the guy who wrote the inotify code in dovecot.
> 
> I'm not so sure userspace should be able or need to cause the kernel to dump 
> stack traces like that though?
> 

Yes, the stack dumps would appear to be due to an inotify bug.

The message from dovecot is allegedly due to dovecot passing in a file
descriptor which was not obtained from the inotify_init() syscall.  But
until we know what caused those stack dumps we cannot definitely say
whether dovecot is at fault.

-
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.13-rc6-mm1

[Reuben Farrelly]

Hi,

On 19/08/2005 11:37 a.m., Andrew Morton wrote:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc6/2.6.13-rc6-mm1/

- Lots of fixes, updates and cleanups all over the place.

- If you have the right debugging options set, this kernel will generate
  a storm of sleeping-in-atomic-code warnings at boot, from the scsi code.
  It is being worked on.


Changes since 2.6.13-rc5-mm1:

 linus.patch


Noted this in my log earlier today.

Is this inotify related?

Aug 21 08:33:04 tornado kernel: idr_remove called for id=2048 which is not 
allocated.

Aug 21 08:33:04 tornado kernel:  [] dump_stack+0x17/0x19
Aug 21 08:33:04 tornado kernel:  [] idr_remove_warning+0x1b/0x1d
Aug 21 08:33:04 tornado kernel:  [] sub_remove+0x88/0xea
Aug 21 08:33:04 tornado kernel:  [] idr_remove+0x1b/0x7f
Aug 21 08:33:04 tornado kernel:  [] remove_watch_no_event+0x7a/0x12e
Aug 21 08:33:04 tornado kernel:  [] inotify_release+0x8f/0x1af
Aug 21 08:33:04 tornado kernel:  [] __fput+0xaf/0x199
Aug 21 08:33:04 tornado kernel:  [] fput+0x22/0x3b
Aug 21 08:33:04 tornado kernel:  [] filp_close+0x41/0x67
Aug 21 08:33:04 tornado kernel:  [] sys_close+0x70/0x92
Aug 21 08:33:04 tornado kernel:  [] sysenter_past_esp+0x54/0x75
Aug 21 08:33:04 tornado kernel: idr_remove called for id=3072 which is not 
allocated.

Aug 21 08:33:05 tornado kernel:  [] dump_stack+0x17/0x19
Aug 21 08:33:05 tornado kernel:  [] idr_remove_warning+0x1b/0x1d
Aug 21 08:33:05 tornado kernel:  [] sub_remove+0x88/0xea
Aug 21 08:33:05 tornado kernel:  [] idr_remove+0x1b/0x7f
Aug 21 08:33:05 tornado kernel:  [] remove_watch_no_event+0x7a/0x12e
Aug 21 08:33:05 tornado kernel:  [] inotify_release+0x8f/0x1af
Aug 21 08:33:05 tornado kernel:  [] __fput+0xaf/0x199
Aug 21 08:33:05 tornado kernel:  [] fput+0x22/0x3b
Aug 21 08:33:05 tornado kernel:  [] filp_close+0x41/0x67
Aug 21 08:33:05 tornado kernel:  [] sys_close+0x70/0x92
Aug 21 08:33:05 tornado kernel:  [] sysenter_past_esp+0x54/0x75

This would have been triggered by using dovecot IMAP which is configured to 
use inotify on Maildir.

I'm also seeing some userspace errors logged for dovecot:

"Aug 21 04:17:22 Error: IMAP(reuben): inotify_rm_watch() failed: Invalid 
argument"

I'll deal with those with the guy who wrote the inotify code in dovecot.

I'm not so sure userspace should be able or need to cause the kernel to dump 
stack traces like that though?


reuben

-
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.13-rc6-mm1

[Reuben Farrelly]

Hi,

On 21/08/2005 1:40 a.m., David Woodhouse wrote:

On Fri, 2005-08-19 at 18:36 -0700, Andrew Morton wrote:

Reuben Farrelly <[EMAIL PROTECTED]> wrote:

...

4. PAM is complaining about "PAM audit_open() failed: Protocol not suppor
ted" and I can't log in as any user including root.  I would have picked this 
was a userspace problem, but it doesn't break with -rc5-mm1, yet reproduceably 
breaks with -rc6-mm1.  Weird.

hm.  How come you're able to use the machine then?
Machine was booting up ok, and things were being written to syslog.  Rebooted 
into -rc5-mm1 to investigate, and of course could boot into rc6-mm1 in single 
user mode, test and bring services up one by one from there.  Having two boxes 
helped too.



Is it possible to get an strace of this failure somehow?
Not sure if this is needed anymore, as I found that the problem goes away when 
I compile in kernel auditing.  This not required for -rc5-mm1.  Is that change 
intended?



Sounds wrong to me, especially if 2.6.13-rc6 doesn't do that.


Hm. It sounds like you'd configured PAM to require the pam_loginuid
module even though you didn't have auditing enabled in your kernel. That
seems strange and wrong to me, and _is_ a userspace problem.


I haven't touched my pam config since it was installed a long time ago - it's 
one of those things that is too annoying to fix once broked, so I leave it 
alone at the system defaults ;)


I had logged this as a Fedora bug as I figured the pam_loginuid
detection of the presence of auditing in the kernel is not very robust.  There 
was a patch modified in pam-0.80-6 at the start of August which was to fix 
this on non audit enabled kernels, which works for anything up to and older 
than 2.6.12-rc5-mm1.


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166422

It was closed 8 mins later, and the suggestion made that I take it to a pam 
development list instead.  Redhat don't seem so interested in fixing things as 
a result of breakage when running an -mm kernel.



I'd also agree that it shouldn't have changed with the new kernel though
-- and I can't think of anything I changed recently which would have
that effect. An strace would still be useful.


Done.  Posted up at  http://www.reub.net/kernel/strace-login


Can you double-check that you didn't have auditing enabled in your
older, working kernel?


Definitely wasn't enabled.  I still have the .config that I used to build
-rc5-mm1 with and my original -rc6-mm1 and it reads:

CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_HOTPLUG=y

Thanks for taking a look.

Reuben




-
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.13-rc6-mm1: git-ocfs2.patch breaks jffs

[Adrian Bunk]

On Fri, Aug 19, 2005 at 04:33:31AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.13-rc5-mm1:
>...
>  git-ocfs2.patch
>...
>  Subsystem trees
>...

gcc correctly tells that at least a part of this patch incorrect (not 
that gcc says "is used", not "might be used"):

<--  snip  -->

...
  CC  fs/jffs/inode-v23.o
fs/jffs/inode-v23.c: In function 'jffs_create':
fs/jffs/inode-v23.c:1282: warning: 'inode' is used uninitialized in this 
function
...

<--  snip  -->

Looking at the code, it's trivial to verify that gcc is right.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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.13-rc6-mm1 [i6300escb.c 2 bugs, little cleanup]

[Jiri Slaby]

In i6300esb.c watchdog card driver were 2 bugs (misused pc_match_device
and pci_dev_put wasn't called in one error case) and one little cleanup
was done (long line was converted to a shorter one with using built-in
macro).

Generated in 2.6.13-rc6-mm1 kernel version.

Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>

i6300esb.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/char/watchdog/i6300esb.c b/drivers/char/watchdog/i6300esb.c
--- a/drivers/char/watchdog/i6300esb.c
+++ b/drivers/char/watchdog/i6300esb.c
@@ -349,7 +349,7 @@ static struct notifier_block esb_notifie
  * want to register another driver on the same PCI id.
  */
 static struct pci_device_id esb_pci_tbl[] = {
-{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB_9, PCI_ANY_ID, 
PCI_ANY_ID, },
+{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB_9), },
 { 0, }, /* End of list */
 };
 MODULE_DEVICE_TABLE (pci, esb_pci_tbl);
@@ -369,7 +369,7 @@ static unsigned char __init esb_getdevic
  */
 
 for_each_pci_dev(dev)
-if (pci_match_device(esb_pci_tbl, dev)) {
+if (pci_match_id(esb_pci_tbl, dev)) {
 esb_pci = dev;
 break;
 }
@@ -377,7 +377,7 @@ static unsigned char __init esb_getdevic
 if (esb_pci) {
if (pci_enable_device(esb_pci)) {
printk (KERN_ERR PFX "failed to enable device\n");
-   goto out;
+   goto err_devput;
}
 
if (pci_request_region(esb_pci, 0, ESB_MODULE_NAME)) {
@@ -429,9 +429,10 @@ err_release:
pci_release_region(esb_pci, 0);
 err_disable:
pci_disable_device(esb_pci);
+err_devput:
pci_dev_put(esb_pci);
}
-out:
+
return 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/

Re: 2.6.13-rc6-mm1

[Martin J. Bligh]

--Andrew Morton <[EMAIL PROTECTED]> wrote (on Friday, August 19, 2005 04:33:31 
-0700):

> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc6/2.6.13-rc6-mm1/
> 
> - Lots of fixes, updates and cleanups all over the place.
> 
> - If you have the right debugging options set, this kernel will generate
>   a storm of sleeping-in-atomic-code warnings at boot, from the scsi code.
>   It is being worked on.

Get a couple of debug warnings as you mention ... but then it panics.


scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0

aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs

scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0

aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs

  Vendor: IBM   Model: GNHv1 S2  Rev: 0   
  Type:   Processor  ANSI SCSI revision: 02
 target1:0:9: Beginning Domain Validation
 target1:0:9: Ending Domain Validation
  Vendor: IBM-ESXS  Model: DTN036C1UCDY10F   Rev: S25J
  Type:   Direct-Access  ANSI SCSI revision: 03
scsi1:A:12:0: Tagged Queuing enabled.  Depth 253
 target1:0:12: Beginning Domain Validation
 target1:0:12: wide asynchronous.
 target1:0:12: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 127)
 target1:0:12: Ending Domain Validation
  Vendor: IBM-ESXS  Model: DTN036C1UCDY10F   Rev: S25J
  Type:   Direct-Access  ANSI SCSI revision: 03
scsi1:A:13:0: Tagged Queuing enabled.  Depth 253
 target1:0:13: Beginning Domain Validation
 target1:0:13: wide asynchronous.
 target1:0:13: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 127)
 target1:0:13: Ending Domain Validation
scsi2 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0

aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs

scheduling while atomic: swapper/0x0100/0
 [] schedule+0x45/0x724
 [] __wake_up+0x31/0x3c
 [] dcache_shrinker_del+0x2e/0x38
 [] dput_recursive+0x232/0x270
 [] dput_recursive+0x265/0x270
 [] __down+0x7f/0x108
 [] default_wake_function+0x0/0x1c
 [] __down_failed+0x7/0xc
 [] .text.lock.attribute_container+0x8b/0xc1
 [] transport_remove_device+0xf/0x14
 [] transport_remove_classdev+0x0/0x58
 [] scsi_target_reap+0x86/0xb4
 [] scsi_device_dev_release+0x134/0x15c
 [] device_release+0x14/0x4c
 [] kobject_cleanup+0x47/0x6c
 [] kobject_release+0x0/0x14
 [] kobject_release+0xd/0x14
 [] kref_put+0x79/0x89
 [] kobject_put+0x16/0x1c
 [] kobject_release+0x0/0x14
 [] put_device+0x11/0x18
 [] scsi_put_command+0xa5/0xb0
 [] scsi_next_command+0x11/0x1c
 [] scsi_end_request+0xa9/0xb4
 [] scsi_io_completion+0x489/0x494
 [] scsi_generic_done+0x32/0x38
 [] scsi_finish_command+0xa0/0xa8
 [] scsi_softirq+0x139/0x154
 [] __do_softirq+0x8d/0x100
 [] do_softirq+0x2f/0x34
 [] irq_exit+0x34/0x38
 [] do_IRQ+0x20/0x28
 [] common_interrupt+0x1a/0x20
 [] default_idle+0x0/0x2c
 [] default_idle+0x23/0x2c
 [] cpu_idle+0x7b/0x8c
 [] rest_init+0x28/0x2c
 [] start_kernel+0x197/0x19c
scheduling while atomic: swapper/0x0100/0
 [] schedule+0x45/0x724
 [] default_wake_function+0x17/0x1c
 [] __wake_up_common+0x37/0x50
 [] __wake_up+0x31/0x3c
 [] wait_for_completion+0x90/0xe8
 [] default_wake_function+0x0/0x1c
 [] default_wake_function+0x0/0x1c
 [] call_usermodehelper_keys+0x144/0x15a
 [] __call_usermodehelper+0x0/0x4c
 [] __call_usermodehelper+0x0/0x4c
 [] kobject_hotplug+0x255/0x280
 [] class_device_del+0x8d/0xa8
 [] attribute_container_class_device_del+0x11/0x18
 [] transport_remove_classdev+0x4f/0x58
 [] attribute_container_device_trigger+0x7f/0xb8
 [] transport_remove_device+0xf/0x14
 [] transport_remove_classdev+0x0/0x58
 [] scsi_target_reap+0x86/0xb4
 [] scsi_device_dev_release+0x134/0x15c
 [] device_release+0x14/0x4c
 [] kobject_cleanup+0x47/0x6c
 [] kobject_release+0x0/0x14
 [] kobject_release+0xd/0x14
 [] kref_put+0x79/0x89
 [] kobject_put+0x16/0x1c
 [] kobject_release+0x0/0x14
 [] put_device+0x11/0x18
 [] scsi_put_command+0xa5/0xb0
 [] scsi_next_command+0x11/0x1c
 [] scsi_end_request+0xa9/0xb4
 [] scsi_io_completion+0x489/0x494
 [] scsi_generic_done+0x32/0x38
 [] scsi_finish_command+0xa0/0xa8
 [] scsi_softirq+0x139/0x154
 [] __do_softirq+0x8d/0x100
 [] do_softirq+0x2f/0x34
 [] irq_exit+0x34/0x38
 [] do_IRQ+0x20/0x28
 [] common_interrupt+0x1a/0x20
 [] default_idle+0x0/0x2c
 [] default_idle+0x23/0x2c
 [] cpu_idle+0x7b/0x8c
 [] rest_init+0x28/0x2c
 [] start_kernel+0x197/0x19c
Unable to handle kernel NULL pointer dereference at virtual address 
 printing eip:
c0263cf2
*pde = 0042c001
*pte = 
Oops:  [#1]
SMP 
last sysfs file: 
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010282   (2.6.13-rc6-mm1-autokern1) 
EIP is at scsi_run_queue+0xe/0xb4
eax: d777ce30   ebx: d777ce30   ecx: 0282   edx: d6c4cc00
esi: d777ce30   edi:    ebp: 0246   esp: c03dde98
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 0, threadinfo=c03dc000 task=c0373be0)
Stack: d777ce30 d777ce30 d76fb

Re: 2.6.13-rc6-mm1

[David Woodhouse]

On Fri, 2005-08-19 at 18:36 -0700, Andrew Morton wrote:
> Reuben Farrelly <[EMAIL PROTECTED]> wrote:
> >
> > ...
> > >> 4. PAM is complaining about "PAM audit_open() failed: Protocol not suppor
> > >> ted" and I can't log in as any user including root.  I would have picked 
> > >> this 
> > >> was a userspace problem, but it doesn't break with -rc5-mm1, yet 
> > >> reproduceably 
> > >> breaks with -rc6-mm1.  Weird.
> > > 
> > > hm.  How come you're able to use the machine then?
> > 
> > Machine was booting up ok, and things were being written to syslog.  
> > Rebooted 
> > into -rc5-mm1 to investigate, and of course could boot into rc6-mm1 in 
> > single 
> > user mode, test and bring services up one by one from there.  Having two 
> > boxes 
> > helped too.
> > 
> > > Is it possible to get an strace of this failure somehow?
> > 
> > Not sure if this is needed anymore, as I found that the problem goes away 
> > when 
> > I compile in kernel auditing.  This not required for -rc5-mm1.  Is that 
> > change 
> > intended?
> > 
> 
> Sounds wrong to me, especially if 2.6.13-rc6 doesn't do that.

Hm. It sounds like you'd configured PAM to require the pam_loginuid
module even though you didn't have auditing enabled in your kernel. That
seems strange and wrong to me, and _is_ a userspace problem.

I'd also agree that it shouldn't have changed with the new kernel though
-- and I can't think of anything I changed recently which would have
that effect. An strace would still be useful.

Can you double-check that you didn't have auditing enabled in your
older, working kernel?

-- 
dwmw2

-
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.13-rc6-mm1

[Andrew Morton]

Reuben Farrelly <[EMAIL PROTECTED]> wrote:
>
> ...
> >> 4. PAM is complaining about "PAM audit_open() failed: Protocol not suppor
> >> ted" and I can't log in as any user including root.  I would have picked 
> >> this 
> >> was a userspace problem, but it doesn't break with -rc5-mm1, yet 
> >> reproduceably 
> >> breaks with -rc6-mm1.  Weird.
> > 
> > hm.  How come you're able to use the machine then?
> 
> Machine was booting up ok, and things were being written to syslog.  Rebooted 
> into -rc5-mm1 to investigate, and of course could boot into rc6-mm1 in single 
> user mode, test and bring services up one by one from there.  Having two 
> boxes 
> helped too.
> 
> > Is it possible to get an strace of this failure somehow?
> 
> Not sure if this is needed anymore, as I found that the problem goes away 
> when 
> I compile in kernel auditing.  This not required for -rc5-mm1.  Is that 
> change 
> intended?
> 

Sounds wrong to me, especially if 2.6.13-rc6 doesn't do that.

David?
-
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.13-rc6-mm1

[Andrew Morton]

Reuben Farrelly <[EMAIL PROTECTED]> wrote:
>
> >> Aug 20 12:26:10 tornado kernel: Device  not ready.
> >>
> >> 2.  That message on the third line of the trace above: "kernel: Device  
> >> not 
> >> ready." is being logged every few mins or so, I believe it is my SCSI 
> >> CDROM 
> >> that is causing it.  It also logs something similar after the SCSI driver 
> >> has 
> >> probed the device on boot:
> >>
> >> Aug 20 12:24:36 tornado kernel: scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI 
> >> HBA 
> >> DRIVER, Rev 7.0
> >> Aug 20 12:24:36 tornado kernel: 
> >> Aug 20 12:24:36 tornado kernel: aic7880: Ultra Wide Channel A, 
> >> SCSI 
> >> Id=7, 16/253 SCBs
> >> Aug 20 12:24:36 tornado kernel:
> >> Aug 20 12:24:36 tornado kernel:   Vendor: SONY  Model: CD-RW  CRX145S 
> >> Rev: 1.0b
> >> Aug 20 12:24:36 tornado kernel:   Type:   CD-ROM 
> >> ANSI SCSI revision: 04
> >> Aug 20 12:24:36 tornado kernel:  target0:0:6: Beginning Domain Validation
> >> Aug 20 12:24:36 tornado kernel:  target0:0:6: Domain Validation skipping 
> >> write 
> >> tests
> >> Aug 20 12:24:36 tornado kernel:  target0:0:6: FAST-10 SCSI 10.0 MB/s ST 
> >> (100 
> >> ns, offset 15)
> >> Aug 20 12:24:36 tornado kernel:  target0:0:6: Ending Domain Validation
> >> Aug 20 12:24:36 tornado kernel: Device  not ready.
> >>
> >> This has been a problem for quite a few weeks now, albeit I believe, only 
> >> a 
> >> cosmetic one.
> > 
> > Is some application trying to poll the device?
> 
> I wonder if hald knows something about this and is polling.. however that 
> message above about "Device  not ready" occurs when the kernel is booting, 
> before any userspace stuff has started up.  Maybe hald is just being a bit 
> aggressive in re-probing the drive after userspace launches.  B all accounts 
> after a week of uptime the drive certainly ought to be ready, it seems to 
> work 
> ok ;-)
> 
> Note the extra space after 'Device' and 'not' which implies possibly some 
> text 
> is missing (which would have made it more clear which device is not exactly 
> ready).  The case sensitive strings "Device" and "not ready" appears together 
> in scsi_lib.c and very few other places.

OK, it'll be this:

case NOT_READY:
/*
 * If the device is in the process of becoming ready,
 * retry.
 */
if (sshdr.asc == 0x04 && sshdr.ascq == 0x01) {
scsi_requeue_command(q, cmd);
return;
}
printk(KERN_INFO "Device %s not ready.\n",
   req->rq_disk ? req->rq_disk->disk_name : "");

Where the disk name is evaluating to an empty string.

Maybe you could stick a dump_stack() in there, get some additional info.

Anyway, over to you, James ;)

> > Is the device actually "not ready", or is it in reality ready and working? 
> > ie: what happens if you stick a CD in it?
> 
> The CD can be read, and the error messages go away.  They stay away even 
> after 
> the CD has been ejected.

-
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.13-rc6-mm1

[Reuben Farrelly]

Hi again,

On 20/08/2005 5:34 a.m., Andrew Morton wrote:

Reuben Farrelly <[EMAIL PROTECTED]> wrote:



A few new problems cropped up with this kernel..

1. NFS seems to be unstable, oopsing when shutting down:


--- devel/fs/nfsd/nfssvc.c~ingo-nfs-stuff-fix   2005-08-19 10:29:15.0 
-0700
+++ devel-akpm/fs/nfsd/nfssvc.c 2005-08-19 10:30:03.0 -0700
@@ -286,7 +286,6 @@ out:
/* Release the thread */
svc_exit_thread(rqstp);
 
-	unlock_kernel();

/* Release module */
unlock_kernel();
module_put_and_exit(0);
_


That fixed it, thanks.



Aug 20 12:26:10 tornado kernel: Device  not ready.

2.  That message on the third line of the trace above: "kernel: Device  not 
ready." is being logged every few mins or so, I believe it is my SCSI CDROM 
that is causing it.  It also logs something similar after the SCSI driver has 
probed the device on boot:


Aug 20 12:24:36 tornado kernel: scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA 
DRIVER, Rev 7.0

Aug 20 12:24:36 tornado kernel: 
Aug 20 12:24:36 tornado kernel: aic7880: Ultra Wide Channel A, SCSI 
Id=7, 16/253 SCBs

Aug 20 12:24:36 tornado kernel:
Aug 20 12:24:36 tornado kernel:   Vendor: SONY  Model: CD-RW  CRX145S 
Rev: 1.0b
Aug 20 12:24:36 tornado kernel:   Type:   CD-ROM 
ANSI SCSI revision: 04

Aug 20 12:24:36 tornado kernel:  target0:0:6: Beginning Domain Validation
Aug 20 12:24:36 tornado kernel:  target0:0:6: Domain Validation skipping write 
tests
Aug 20 12:24:36 tornado kernel:  target0:0:6: FAST-10 SCSI 10.0 MB/s ST (100 
ns, offset 15)

Aug 20 12:24:36 tornado kernel:  target0:0:6: Ending Domain Validation
Aug 20 12:24:36 tornado kernel: Device  not ready.

This has been a problem for quite a few weeks now, albeit I believe, only a 
cosmetic one.


Is some application trying to poll the device?


I wonder if hald knows something about this and is polling.. however that 
message above about "Device  not ready" occurs when the kernel is booting, 
before any userspace stuff has started up.  Maybe hald is just being a bit 
aggressive in re-probing the drive after userspace launches.  B all accounts 
after a week of uptime the drive certainly ought to be ready, it seems to work 
ok ;-)


Note the extra space after 'Device' and 'not' which implies possibly some text 
is missing (which would have made it more clear which device is not exactly 
ready).  The case sensitive strings "Device" and "not ready" appears together 
in scsi_lib.c and very few other places.


Is the device actually "not ready", or is it in reality ready and working? 
ie: what happens if you stick a CD in it?


The CD can be read, and the error messages go away.  They stay away even after 
the CD has been ejected.



4. PAM is complaining about "PAM audit_open() failed: Protocol not suppor
ted" and I can't log in as any user including root.  I would have picked this 
was a userspace problem, but it doesn't break with -rc5-mm1, yet reproduceably 
breaks with -rc6-mm1.  Weird.


hm.  How come you're able to use the machine then?


Machine was booting up ok, and things were being written to syslog.  Rebooted 
into -rc5-mm1 to investigate, and of course could boot into rc6-mm1 in single 
user mode, test and bring services up one by one from there.  Having two boxes 
helped too.



Is it possible to get an strace of this failure somehow?


Not sure if this is needed anymore, as I found that the problem goes away when 
I compile in kernel auditing.  This not required for -rc5-mm1.  Is that change 
intended?


reuben
-
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.13-rc6-mm1: why is PHYLIB a user-visible option?

[Jeff Garzik]

Adrian Bunk wrote:

Is there any reason why PHYLIB is a user-visible option?

As far as I understand it, PHYLIB and the MII PHY device drivers are an 
internal library drivers should start to use roughly similar to MII.


But in this case, the options shouldn't be user-visible.


This code is still shaking out, so don't worry much about it right now.

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/

2.6.13-rc6-mm1: why is PHYLIB a user-visible option?

[Adrian Bunk]

Is there any reason why PHYLIB is a user-visible option?

As far as I understand it, PHYLIB and the MII PHY device drivers are an 
internal library drivers should start to use roughly similar to MII.

But in this case, the options shouldn't be user-visible.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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.13-rc6-mm1 broke parallel port printer

[Adrian Bunk]

On Fri, Aug 19, 2005 at 04:33:31AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.13-rc5-mm1:
>...
> +fix-handling-in-parport_pc-init-code.patch
> 
>  parport fix
>...

This patch broke my parallel port printer.

diff between 2.6.13-rc6-mm1 and 2.6.13-rc6-mm1 with this patch reverted
(the reason for the input message being earlier might simply be that 
a working parport initialization takes some time):

<--  snip  -->

...
 radeonfb (:01:00.0): ATI Radeon QY 
 lp: driver loaded but no devices found
 Real Time Clock Driver v1.12
 Non-volatile memory driver v1.2
 Linux agpgart interface v0.101 (c) Dave Jones
 agpgart: Detected SiS 746 chipset
 agpgart: AGP aperture is 64M @ 0xd000
 [drm] Initialized drm 1.0.0 20040925
 ACPI: PCI Interrupt :01:00.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> 
IRQ 11
 [drm] Initialized radeon 1.17.0 20050311 on minor 0: 
 serio: i8042 AUX port at 0x60,0x64 irq 12
 serio: i8042 KBD port at 0x60,0x64 irq 1
 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
 ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
 mice: PS/2 mouse device common for all mice
+parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP]
+parport0: irq 7 detected
+input: AT Translated Set 2 keyboard on isa0060/serio0
+parport0: Legacy device
+lp0: using parport0 (polling).
 io scheduler noop registered
...
 saa7134[0]: board init: gpio is 100a0
-input: AT Translated Set 2 keyboard on isa0060/serio0
 saa7134[0]: Huh, no eeprom present (err=-5)?
...

<--  snip  -->

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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.13-rc6-mm1

[Benoit Boissinot]

On Fri, Aug 19, 2005 at 05:01:05PM -0400, Ed Tomlinson wrote:
> Hi,
> 
> Adding the include to dmi.h allows the compile to get past this point though I
> wonder if this is the correct place to put it?  (Thanks Benoit)
> 
> I now get:
> 
>   CC [M]  net/ipv4/ipvs/ip_vs_ctl.o
> net/ipv4/ipvs/ip_vs_ctl.c:1601: error: static declaration of 'ipv4_table' 
> follows non-static declaration
> include/net/ip.h:376: error: previous declaration of 'ipv4_table' was here
> make[3]: *** [net/ipv4/ipvs/ip_vs_ctl.o] Error 1
> make[2]: *** [net/ipv4/ipvs] Error 2
> make[1]: *** [net/ipv4] Error 2
> make: *** [net] Error 2
> 
> Ideas?
> 

I think the following is patch needed because ipv4_table is local to
ipvs.

Signed-off-by: Benoit Boissinot <[EMAIL PROTECTED]>

--- ./net/ipv4/ipvs/ip_vs_lblc.c2004-12-24 22:35:28.0 +0100
+++ ./net/ipv4/ipvs/ip_vs_lblc.c.new2005-08-19 23:22:09.0 +0200
@@ -131,7 +131,7 @@ static ctl_table vs_table[] = {
{ .ctl_name = 0 }
 };
 
-static ctl_table ipv4_table[] = {
+static ctl_table ipv4_vs_table[] = {
{
.ctl_name   = NET_IPV4,
.procname   = "ipv4", 
@@ -146,7 +146,7 @@ static ctl_table lblc_root_table[] = {
.ctl_name   = CTL_NET,
.procname   = "net", 
.mode   = 0555, 
-   .child  = ipv4_table
+   .child  = ipv4_vs_table
},
{ .ctl_name = 0 }
 };
--- ./net/ipv4/ipvs/ip_vs_lblcr.c   2004-12-24 22:35:24.0 +0100
+++ ./net/ipv4/ipvs/ip_vs_lblcr.c.new   2005-08-19 23:22:25.0 +0200
@@ -320,7 +320,7 @@ static ctl_table vs_table[] = {
{ .ctl_name = 0 }
 };
 
-static ctl_table ipv4_table[] = {
+static ctl_table ipv4_vs_table[] = {
{
.ctl_name   = NET_IPV4,
.procname   = "ipv4", 
@@ -335,7 +335,7 @@ static ctl_table lblcr_root_table[] = {
.ctl_name   = CTL_NET,
.procname   = "net", 
.mode   = 0555, 
-   .child  = ipv4_table
+   .child  = ipv4_vs_table
},
{ .ctl_name = 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/

Re: 2.6.13-rc6-mm1

[Avuton Olrich]

On 8/19/05, Greg KH <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 19, 2005 at 09:42:51AM -0700, Avuton Olrich wrote:
> > On 8/19/05, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > - Lots of fixes, updates and cleanups all over the place.
> >
> > Problem: Badness during boot, seems to pertain to USB serial driver/gameport
> 
> Does this happen in 2.6.13-rc6 (no -mm)?
> 
> I'm trying to reproduce this now (Andrew, I didn't have any such build
> link errors like you did with this config...)

I can't test 2.6.13-rc6 atm, since I have dependance on REISER4_FS=Y

avuton
-- 
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
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.13-rc6-mm1

[Greg KH]

On Fri, Aug 19, 2005 at 09:42:51AM -0700, Avuton Olrich wrote:
> On 8/19/05, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > - Lots of fixes, updates and cleanups all over the place.
> 
> Problem: Badness during boot, seems to pertain to USB serial driver/gameport
> 
> Kernel Version: Linux version 2.6.13-rc6-mm1 ([EMAIL PROTECTED]) (gcc
> version 3.4.4 (Gentoo 3.4.4, ssp-3.4.4-1.0, pie-8.7.8)) #1 PREEMPT Fri
> Aug 19 09:14:10 PDT 2005
> 
> Could not duplicate this in 2.6.13-rc5-mm1

Does this happen in 2.6.13-rc6 (no -mm)?

I'm trying to reproduce this now (Andrew, I didn't have any such build
link errors like you did with this config...)

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.13-rc6-mm1

[Ed Tomlinson]

Hi,

Adding the include to dmi.h allows the compile to get past this point though I
wonder if this is the correct place to put it?  (Thanks Benoit)

I now get:

  CC [M]  net/ipv4/ipvs/ip_vs_ctl.o
net/ipv4/ipvs/ip_vs_ctl.c:1601: error: static declaration of 'ipv4_table' 
follows non-static declaration
include/net/ip.h:376: error: previous declaration of 'ipv4_table' was here
make[3]: *** [net/ipv4/ipvs/ip_vs_ctl.o] Error 1
make[2]: *** [net/ipv4/ipvs] Error 2
make[1]: *** [net/ipv4] Error 2
make: *** [net] Error 2

Ideas?

TIA
Ed Tomlinson

On Friday 19 August 2005 12:04, Benoit Boissinot wrote:
> On 8/19/05, Ed Tomlinson <[EMAIL PROTECTED]> wrote:
> > On Friday 19 August 2005 07:33, Andrew Morton wrote:
> > > - Lots of fixes, updates and cleanups all over the place.
> > >
> > > - If you have the right debugging options set, this kernel will generate
> > > a storm of sleeping-in-atomic-code warnings at boot, from the scsi code.
> > > It is being worked on.
> > >
> > >
> > > Changes since 2.6.13-rc5-mm1:
> > >
> > 
> > Hi,
> > 
> > It does not compile here:
> > 
> >   CC  drivers/acpi/sleep/main.o
> > In file included from drivers/acpi/sleep/main.c:15:
> > include/linux/dmi.h:55: error: field 'list' has incomplete type
> > make[3]: *** [drivers/acpi/sleep/main.o] Error 1
> > make[2]: *** [drivers/acpi/sleep] Error 2
> > make[1]: *** [drivers/acpi] Error 2
> > make: *** [drivers] Error 2
> > [EMAIL PROTECTED]:/usr/src/13-6-1$
> > 
> > Probably a missing include?  Note that this is a non smp x86_64 build.
> > 
> including  in dmi.h should work
> 
> regards,
> 
> Benoit
> -
> 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/
> 
> 
-
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.13-rc6-mm1: remove-asm-hdregh.patch problems

[Andrew Morton]

Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> On Fri, Aug 19, 2005 at 04:33:31AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.13-rc5-mm1:
> >...
> > +remove-asm-hdregh.patch
> > 
> >  cleanup
> >...
> 
> This patch could be improved in two respects:
> - it doesn't remove the xtensa hdreg.h
> - the "removed" files are only empty since the original files are
>   not diffed against /dev/null (or an epoch date)
> 

Thanks, I fixed those up.
-
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.13-rc6-mm1: remove-asm-hdregh.patch problems

[Adrian Bunk]

On Fri, Aug 19, 2005 at 04:33:31AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.13-rc5-mm1:
>...
> +remove-asm-hdregh.patch
> 
>  cleanup
>...

This patch could be improved in two respects:
- it doesn't remove the xtensa hdreg.h
- the "removed" files are only empty since the original files are
  not diffed against /dev/null (or an epoch date)

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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.13-rc6-mm1 - OOPS in drivers/net/phy

[Marc Ballarin]

Hi,
the changes to drivers/net/phy in git-netdev-all.patch have some issues:

1) phy.c (libphy.ko) lacks MODULE_LICENCE(GPL), but uses GPL-only
exports

2) after fixing this (or when compiling statically) it causes the following
OOPS (new in rc6-mm1):

Badness in kref_get at lib/kref.c:32
 [] dump_stack+0x17/0x20
 [] kref_get+0x46/0x50
 [] kobject_get+0x12/0x20
 [] get_bus+0x16/0x30
 [] bus_add_driver+0x19/0xc0
 [] driver_register+0x2a/0x40
 [] phy_driver_register+0x49/0x90 [libphy]
 [] phy_init+0xe/0x40 [libphy]
 [] sys_init_module+0x149/0x1f0
 [] sysenter_past_esp+0x54/0x75
---
| preempt count:  ]
---

Badness in kref_get at lib/kref.c:32
 [] dump_stack+0x17/0x20
 [] kref_get+0x46/0x50
 [] kobject_get+0x12/0x20
 [] kobject_init+0x28/0x40
 [] kobject_register+0x1c/0x70
 [] bus_add_driver+0x54/0xc0
 [] driver_register+0x2a/0x40
 [] phy_driver_register+0x49/0x90 [libphy]
 [] phy_init+0xe/0x40 [libphy]
 [] sys_init_module+0x149/0x1f0
 [] sysenter_past_esp+0x54/0x75
---
| preempt count:  ]
---

Unable to handle kernel NULL pointer dereference at virtual address 
 printing eip:
c01c3894
*pde = 
Oops: 0002 [#1]
PREEMPT 
last sysfs file: /class/vc/vcs3/dev
Modules linked in: libphy snd_pcm_oss snd_mixer_oss snd_seq_oss 
snd_seq_midi_event snd_seq snd_seq_device snd_intel8x0 snd_ac97_codec 
snd_ac97_bus snd_pcm snd_timer snd snd_page_alloc ntfs vfat fat reiser4 
zlib_deflate zlib_inflate usb_storage loop acpi_cpufreq yealink usbhid joydev 
acpi_sbs i2c_acpi_ec bcm4400 ehci_hcd uhci_hcd usbcore intel_agp agpgart psmouse
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010292   (2.6.13-rc6-mm1-laptop) 
EIP is at kobject_add+0x94/0xd0
eax: f18d4140   ebx: f18d406c   ecx:    edx: f18d4088
esi: ffea   edi: f18d4148   ebp: ed089f14   esp: ed089f08
ds: 007b   es: 007b   ss: 0068
Process modprobe (pid: 8250, threadinfo=ed088000 task=efd7c690)
Stack: f18d406c ffea f18d40e0 ed089f30 c01c38f3 ed089f44  f18d4058 
   f18d4058 f18d406c ed089f54 c02363c4 f18d406c c0315706 f18d338f  
   f18d4058 0805b198 f18d40dc ed089f70 c0236d1a  0011 000b 
Call Trace:
 [] show_stack+0x7a/0x90
 [] show_registers+0x158/0x1c0
 [] die+0xf5/0x180
 [] do_page_fault+0x2a4/0x59d
 [] error_code+0x4f/0x54
 [] kobject_register+0x23/0x70
 [] bus_add_driver+0x54/0xc0
 [] driver_register+0x2a/0x40
 [] phy_driver_register+0x49/0x90 [libphy]
 [] phy_init+0xe/0x40 [libphy]
 [] sys_init_module+0x149/0x1f0
 [] sysenter_past_esp+0x54/0x75
---
| preempt count: 0002 ]
| 2 level deep critical section nesting:

.. []  kobject_add+0x7e/0xd0
.[] ..   ( <= kobject_register+0x23/0x70)
.. []  die+0x38/0x180
.[] ..   ( <= do_page_fault+0x2a4/0x59d)

Code: 74 e2 89 f8 e8 ce 02 00 00 eb d9 b8 01 00 00 00 e8 12 4d 00 00 85 ff 74 
36 8b 43 28 8d 53 1c 83 c0 08 89 43 1c 8b 48 04 89 50 04 <89> 11 89 4a 04 b8 01 
00 00 00 e8 4d 4d 00 00 b8 00 e0 ff ff 21 
 <3>BUG: modprobe[8250] exited with nonzero preempt_count 1!
---
| preempt count: 0001 ]
| 1 level deep critical section nesting:

.. []  kobject_add+0x7e/0xd0
.[] ..   ( <= kobject_register+0x23/0x70)

-
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.13-rc6-mm1

[Andrew Morton]

Dave Kleikamp <[EMAIL PROTECTED]> wrote:
>
> It seems that git-ocfs2.patch duplicates the
> update-filesystems-for-new-delete_inode-behavior.patch.  I noticed it
> adds duplicate statements like:
> 
> diff -puN fs/ext2/inode.c~git-ocfs2 fs/ext2/inode.c
> diff -puN fs/ext3/inode.c~git-ocfs2 fs/ext3/inode.c
> --- devel/fs/ext3/inode.c~git-ocfs2 2005-08-18 22:00:35.0 -0700
> +++ devel-akpm/fs/ext3/inode.c  2005-08-18 22:00:37.0 -0700
> @@ -189,6 +189,8 @@ void ext3_delete_inode (struct inode * i
> 
> truncate_inode_pages(&inode->i_data, 0);
> 
> +   truncate_inode_pages(&inode->i_data, 0);
> +
> if (is_bad_inode(inode))
> goto no_delete;

Oh crap, thanks.  I'll fix that up differently somehow.
-
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.13-rc6-mm1

[hallyn]

I get a compile error due to the removal of scsi_cmd->timeout.

I have no idea whether the following is correct (I doubt it is), but
it does fix a compile error, and the resulting kernel at least
survives repeated dbench'es.

thanks,
-serge

Signed-off-by: Serge Hallyn <[EMAIL PROTECTED]
--
 ibmvscsi.c |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.13-rc6-mm1/drivers/scsi/ibmvscsi/ibmvscsi.c
===
--- linux-2.6.13-rc6-mm1.orig/drivers/scsi/ibmvscsi/ibmvscsi.c  2005-08-19 
17:39:38.0 -0500
+++ linux-2.6.13-rc6-mm1/drivers/scsi/ibmvscsi/ibmvscsi.c   2005-08-19 
18:11:02.0 -0500
@@ -594,7 +594,7 @@ static int ibmvscsi_queuecommand(struct 
init_event_struct(evt_struct,
  handle_cmd_rsp,
  VIOSRP_SRP_FORMAT,
- cmnd->timeout);
+ jiffies - cmnd->jiffies_at_alloc);
 
evt_struct->cmnd = cmnd;
evt_struct->cmnd_done = done;
-
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.13-rc6-mm1

[Jesper Juhl]

On 8/19/05, Andrew Morton <[EMAIL PROTECTED]> wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc6/2.6.13-rc6-mm1/
> 

menuconfig complains a little :

$ make menuconfig
scripts/kconfig/mconf arch/i386/Kconfig
drivers/char/Kconfig:847:warning: 'select' used by config symbol
'TANBAC_TB0219' refer to undefined symbol 'PCI_VR41XX'

otherwise things seem to be ok here.


-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.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.13-rc6-mm1

[Andrew Morton]

Reuben Farrelly <[EMAIL PROTECTED]> wrote:
>
> Hi,
> 
> On 19/08/2005 11:33 p.m., Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc6/2.6.13-rc6-mm1/
> > 
> > - Lots of fixes, updates and cleanups all over the place.
> > 
> > - If you have the right debugging options set, this kernel will generate
> >   a storm of sleeping-in-atomic-code warnings at boot, from the scsi code.
> >   It is being worked on.
> 
> A few new problems cropped up with this kernel..
> 
> 1. NFS seems to be unstable, oopsing when shutting down:

--- devel/fs/nfsd/nfssvc.c~ingo-nfs-stuff-fix   2005-08-19 10:29:15.0 
-0700
+++ devel-akpm/fs/nfsd/nfssvc.c 2005-08-19 10:30:03.0 -0700
@@ -286,7 +286,6 @@ out:
/* Release the thread */
svc_exit_thread(rqstp);
 
-   unlock_kernel();
/* Release module */
unlock_kernel();
module_put_and_exit(0);
_

> ...
> Aug 20 12:26:10 tornado kernel: Device  not ready.
> 
> 2.  That message on the third line of the trace above: "kernel: Device  not 
> ready." is being logged every few mins or so, I believe it is my SCSI CDROM 
> that is causing it.  It also logs something similar after the SCSI driver has 
> probed the device on boot:
> 
> Aug 20 12:24:36 tornado kernel: scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA 
> DRIVER, Rev 7.0
> Aug 20 12:24:36 tornado kernel: 
> Aug 20 12:24:36 tornado kernel: aic7880: Ultra Wide Channel A, SCSI 
> Id=7, 16/253 SCBs
> Aug 20 12:24:36 tornado kernel:
> Aug 20 12:24:36 tornado kernel:   Vendor: SONY  Model: CD-RW  CRX145S 
> Rev: 1.0b
> Aug 20 12:24:36 tornado kernel:   Type:   CD-ROM 
> ANSI SCSI revision: 04
> Aug 20 12:24:36 tornado kernel:  target0:0:6: Beginning Domain Validation
> Aug 20 12:24:36 tornado kernel:  target0:0:6: Domain Validation skipping 
> write 
> tests
> Aug 20 12:24:36 tornado kernel:  target0:0:6: FAST-10 SCSI 10.0 MB/s ST (100 
> ns, offset 15)
> Aug 20 12:24:36 tornado kernel:  target0:0:6: Ending Domain Validation
> Aug 20 12:24:36 tornado kernel: Device  not ready.
> 
> This has been a problem for quite a few weeks now, albeit I believe, only a 
> cosmetic one.

Is some application trying to poll the device?

Is the device actually "not ready", or is it in reality ready and working? 
ie: what happens if you stick a CD in it?

> 3. As I have a Marvell Yukon 2 chipset, I was _delighted_ to see a new driver 
> from Stephen Hemmingway appear in the netdev tree for it.  However it seems 
> to 
> be a bit broken, I get link up and a bit of traffic before it just stops 
> passing traffic of any sort and requires an rmmod/modprobe to get going 
> again. 
>   I've emailed him directly about this.

OK.

> 4. PAM is complaining about "PAM audit_open() failed: Protocol not suppor
> ted" and I can't log in as any user including root.  I would have picked this 
> was a userspace problem, but it doesn't break with -rc5-mm1, yet 
> reproduceably 
> breaks with -rc6-mm1.  Weird.

hm.  How come you're able to use the machine then?

Is it possible to get an strace of this failure somehow?

-
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.13-rc6-mm1: too many 'ipv4_table' variables

[Adrian Bunk]

On Fri, Aug 19, 2005 at 04:33:31AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.13-rc5-mm1:
>...
>  git-net.patch
>...
>  Subsystem trees
>...

It seems there are too many different 'ipv4_table' variables:

<--  snip  -->

...
  CC  net/ipv4/ipvs/ip_vs_ctl.o
net/ipv4/ipvs/ip_vs_ctl.c:1601: error: static declaration of 'ipv4_table' 
follows non-static declaration
include/net/ip.h:376: error: previous declaration of 'ipv4_table' was here
make[3]: *** [net/ipv4/ipvs/ip_vs_ctl.o] Error 1

<--  snip  -->

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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.13-rc6-mm1

[Avuton Olrich]

On 8/19/05, Andrew Morton <[EMAIL PROTECTED]> wrote:
> - Lots of fixes, updates and cleanups all over the place.

Problem: Badness during boot, seems to pertain to USB serial driver/gameport

Kernel Version: Linux version 2.6.13-rc6-mm1 ([EMAIL PROTECTED]) (gcc
version 3.4.4 (Gentoo 3.4.4, ssp-3.4.4-1.0, pie-8.7.8)) #1 PREEMPT Fri
Aug 19 09:14:10 PDT 2005

Could not duplicate this in 2.6.13-rc5-mm1

/proc/cpuinfo: 
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 10
model name  : AMD Athlon(tm) XP 2800+
stepping: 0
cpu MHz : 2088.048
cache size  : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
bogomips: 4179.11

Dumps:
[4294679.199000] drivers/usb/serial/usb-serial.c: USB Serial Driver core v2.0
[4294679.199000] Badness in kref_get at lib/kref.c:32
[4294679.199000]  [] kref_get+0x3c/0x40
[4294679.199000]  [] kobject_get+0xf/0x20
[4294679.199000]  [] get_bus+0xe/0x20
[4294679.199000]  [] bus_add_driver+0x1f/0xd0
[4294679.199000]  [] driver_register+0x25/0x30
[4294679.199000]  [] gameport_handle_events+0x85/0x90
[4294679.199000]  [] gameport_thread+0x19/0x100
[4294679.199000]  [] schedule+0x309/0x670
[4294679.199000]  [] gameport_thread+0x0/0x100
[4294679.199000]  [] kthread+0x95/0xd0
[4294679.199000]  [] kthread+0x0/0xd0
[4294679.199000]  [] kernel_thread_helper+0x5/0x10
[4294679.199000] Badness in kref_get at lib/kref.c:32
[4294679.199000]  [] kref_get+0x3c/0x40
[4294679.199000]  [] kobject_get+0xf/0x20
[4294679.199000]  [] kobject_init+0x25/0x40
[4294679.20]  [] kobject_register+0x1b/0x70
[4294679.20]  [] bus_add_driver+0x6e/0xd0
[4294679.20]  [] driver_register+0x25/0x30
[4294679.20]  [] gameport_handle_events+0x85/0x90
[4294679.20]  [] gameport_thread+0x19/0x100
[4294679.20]  [] schedule+0x309/0x670
[4294679.20]  [] gameport_thread+0x0/0x100
[4294679.20]  [] kthread+0x95/0xd0
[4294679.20]  [] kthread+0x0/0xd0
[4294679.20]  [] kernel_thread_helper+0x5/0x10
[4294679.20] Unable to handle kernel NULL pointer dereference at
virtual address 
[4294679.20]  printing eip:
[4294679.20] c023eee5
[4294679.20] *pde = 
[4294679.20] Oops: 0002 [#1]
[4294679.20] PREEMPT
[4294679.20] last sysfs file:
[4294679.20] Modules linked in:
[4294679.20] CPU:0
[4294679.20] EIP:0060:[]Not tainted VLI
[4294679.20] EFLAGS: 00010292   (2.6.13-rc6-mm1)
[4294679.20] EIP is at kobject_add+0x55/0xc0
[4294679.20] eax: c0493920   ebx: c048b368   ecx:    edx: c048b384
[4294679.20] esi: f7f82000   edi: c0493928   ebp:    esp: f7f83f0c
[4294679.20] ds: 007b   es: 007b   ss: 0068
[4294679.20] Process kgameportd (pid: 314, threadinfo=f7f82000
task=f7e885a0)
[4294679.20] Stack: c048b368 ffea c04938c0 c023ef72 
c048b354 c048b368 c048b354
[4294679.20]c048b368 c02b06ae c048b368 c044026e c043b5eb
c048b354 f7f83f98 
[4294679.20]f7f82000 c02b1015 f7e885a0 0296 f7f82000
f7f83f98 f7e9f3e0 c0348805
[4294679.20] Call Trace:
[4294679.20]  [] kobject_register+0x22/0x70
[4294679.20]  [] bus_add_driver+0x6e/0xd0
[4294679.20]  [] driver_register+0x25/0x30
[4294679.20]  [] gameport_handle_events+0x85/0x90
[4294679.20]  [] gameport_thread+0x19/0x100
[4294679.20]  [] schedule+0x309/0x670
[4294679.20]  [] gameport_thread+0x0/0x100
[4294679.20]  [] kthread+0x95/0xd0
[4294679.20]  [] kthread+0x0/0xd0
[4294679.20]  [] kernel_thread_helper+0x5/0x10
[4294679.20] Code: 00 00 8b 4b 28 89 c7 85 c9 74 2f be 00 e0 ff ff
21 e6 ff 46 14 85 c0 74 61 8b 43 28 8d 53 1c 83 c0 08 8b 48 04 89 43
1c 89 50 04 <89> 11 89 4a 04 8b 46 08 ff 4e 14 a8 08 75
4f 89 7b 24 89 d8 e8
[4294679.20]  <3>BUG: kgameportd[314] exited with nonzero preempt_count 1!

The Config:
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.13-rc6-mm1
# Fri Aug 19 08:58:22 2005
#
CONFIG_X86=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

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

#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
C

Re: 2.6.13-rc6-mm1: drivers/scsi/aic7xxx/ compile error

[Christoph Hellwig]

On Fri, Aug 19, 2005 at 06:40:36PM +0200, Adrian Bunk wrote:
> <--  snip  -->
> 
> ...
>   LD  drivers/scsi/aic7xxx/built-in.o
> drivers/scsi/aic7xxx/aic79xx.o: In function `aic_parse_brace_option':
> : multiple definition of `aic_parse_brace_option'
> drivers/scsi/aic7xxx/aic7xxx.o:: first defined here
> make[3]: *** [drivers/scsi/aic7xxx/built-in.o] Error 1
> 
> <--  snip  -->
> 
> 
> #includ'ing .c files is considered harmful...

That code previously had a hack to rename those that I removed
accidentally.  I think we should just kill aiclib.c and keep two
copies of the two functions it still has - they'll go away soon anyway.
I'll cook up a patch and sent it to James ASAP.

-
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.13-rc6-mm1: drivers/scsi/aic7xxx/ compile error

[Adrian Bunk]

<--  snip  -->

...
  LD  drivers/scsi/aic7xxx/built-in.o
drivers/scsi/aic7xxx/aic79xx.o: In function `aic_parse_brace_option':
: multiple definition of `aic_parse_brace_option'
drivers/scsi/aic7xxx/aic7xxx.o:: first defined here
make[3]: *** [drivers/scsi/aic7xxx/built-in.o] Error 1

<--  snip  -->


#includ'ing .c files is considered harmful...


cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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.13-rc6-mm1

[Dave Kleikamp]

It seems that git-ocfs2.patch duplicates the
update-filesystems-for-new-delete_inode-behavior.patch.  I noticed it
adds duplicate statements like:

diff -puN fs/ext2/inode.c~git-ocfs2 fs/ext2/inode.c
diff -puN fs/ext3/inode.c~git-ocfs2 fs/ext3/inode.c
--- devel/fs/ext3/inode.c~git-ocfs2 2005-08-18 22:00:35.0 -0700
+++ devel-akpm/fs/ext3/inode.c  2005-08-18 22:00:37.0 -0700
@@ -189,6 +189,8 @@ void ext3_delete_inode (struct inode * i

truncate_inode_pages(&inode->i_data, 0);

+   truncate_inode_pages(&inode->i_data, 0);
+
if (is_bad_inode(inode))
goto no_delete;

Thanks,
Shaggy
-- 
David Kleikamp
IBM Linux Technology Center

-
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.13-rc6-mm1

[Benoit Boissinot]

On 8/19/05, Ed Tomlinson <[EMAIL PROTECTED]> wrote:
> On Friday 19 August 2005 07:33, Andrew Morton wrote:
> > - Lots of fixes, updates and cleanups all over the place.
> >
> > - If you have the right debugging options set, this kernel will generate
> > a storm of sleeping-in-atomic-code warnings at boot, from the scsi code.
> > It is being worked on.
> >
> >
> > Changes since 2.6.13-rc5-mm1:
> >
> 
> Hi,
> 
> It does not compile here:
> 
>   CC  drivers/acpi/sleep/main.o
> In file included from drivers/acpi/sleep/main.c:15:
> include/linux/dmi.h:55: error: field 'list' has incomplete type
> make[3]: *** [drivers/acpi/sleep/main.o] Error 1
> make[2]: *** [drivers/acpi/sleep] Error 2
> make[1]: *** [drivers/acpi] Error 2
> make: *** [drivers] Error 2
> [EMAIL PROTECTED]:/usr/src/13-6-1$
> 
> Probably a missing include?  Note that this is a non smp x86_64 build.
> 
including  in dmi.h should work

regards,

Benoit
-
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.13-rc6-mm1

[Ed Tomlinson]

On Friday 19 August 2005 07:33, Andrew Morton wrote:
> - Lots of fixes, updates and cleanups all over the place.
> 
> - If you have the right debugging options set, this kernel will generate
>   a storm of sleeping-in-atomic-code warnings at boot, from the scsi code.
>   It is being worked on.
> 
> 
> Changes since 2.6.13-rc5-mm1:
> 

Hi,

It does not compile here:

  CC  drivers/acpi/sleep/main.o
In file included from drivers/acpi/sleep/main.c:15:
include/linux/dmi.h:55: error: field 'list' has incomplete type
make[3]: *** [drivers/acpi/sleep/main.o] Error 1
make[2]: *** [drivers/acpi/sleep] Error 2
make[1]: *** [drivers/acpi] Error 2
make: *** [drivers] Error 2
[EMAIL PROTECTED]:/usr/src/13-6-1$  

Probably a missing include?  Note that this is a non smp x86_64 build.

Thanks
Ed Tomlinson
-
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.13-rc6-mm1: drivers/net/s2io.c: compile error with gcc 4.0

[Adrian Bunk]

On Fri, Aug 19, 2005 at 04:33:31AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.13-rc5-mm1:
>...
> -git-netdev-chelsio.patch
> -git-netdev-e100.patch
> -git-netdev-sis190.patch
> -git-netdev-smc91x-eeprom.patch
> -git-netdev-ieee80211-wifi.patch
> -git-netdev-upstream.patch
> +git-netdev-all.patch
> 
>  And a consolidated netdev tree
>...

This patch causes the following compile error with gcc 4.0:

<--  snip  -->

...
  CC  drivers/net/s2io.o
In file included from drivers/net/s2io.c:65:
drivers/net/s2io.h: In function 'readq':
drivers/net/s2io.h:765: error: invalid lvalue in assignment
drivers/net/s2io.h:766: error: invalid lvalue in assignment
drivers/net/s2io.c: In function 'init_shared_mem':
drivers/net/s2io.c:541: warning: cast from pointer to integer of different size
drivers/net/s2io.c:544: warning: cast to pointer from integer of different size
drivers/net/s2io.c:550: warning: cast from pointer to integer of different size
drivers/net/s2io.c:553: warning: cast to pointer from integer of different size
make[2]: *** [drivers/net/s2io.o] Error 1

<--  snip  -->

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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.13-rc6-mm1

[Brice Goglin]

Le 19.08.2005 15:45, Russell King a écrit :
> #ifdef CONFIG_SMP
> extern int smp_nmi_call_function(void (*fn)(void *), void *priv, int
whatever);
> #else
> static inline int smp_nmi_call_function(void (*fn)(void *), void
*priv, int whatever)
> {
>   return 0;
> }
> #endif
>
> Obviously I've probably got the arguments to smp_nmi_call_function()
> wrong, so they'll need fixing.  I'm sure the above will point you in
> the right direction though.

Thanks, that worked.
Patch attached.
We might have to do the same for smp_call_function one day.

Brice


--- linux-mm/include/linux/smp.h.old2005-08-19 15:55:03.0 +0200
+++ linux-mm/include/linux/smp.h2005-08-19 15:54:01.0 +0200
@@ -100,12 +100,16 @@ void smp_prepare_boot_cpu(void);
 #define raw_smp_processor_id() 0
 #define hard_smp_processor_id()0
 #define smp_call_function(func,info,retry,wait)({ 0; })
-#define smp_nmi_call_function(func, info, wait)({ 0; })
 #define on_each_cpu(func,info,retry,wait)  ({ func(info); 0; })
 static inline void smp_send_reschedule(int cpu) { }
 #define num_booting_cpus() 1
 #define smp_prepare_boot_cpu() do {} while (0)

+static inline int smp_nmi_call_function (smp_nmi_function func,
+void *info, int wait) {
+   return 0;
+}
+
 #endif /* !SMP */

 /*

-
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.13-rc6-mm1

[Russell King]

On Fri, Aug 19, 2005 at 03:41:29PM +0200, Brice Goglin wrote:
> Le 19.08.2005 15:27, Russell King a écrit :
> > Since you're going to be adding #ifdef CONFIG_SMP...#endif around each
> > of these, why not fix where it's declared/defined to be empty?
> 
> Probably because I'm too lazy to find a nice way to fix it :)
> 
> smp_nmi_call_function may return an error but I don't see any place
> where the return value is actually checked. If the error case is
> actually possible, we should check the return value, and the warning
> would disappear.
> 
> Sorry but I'm not familiar enough with this code to know what's the
> good solution :(

Well, I don't have access to the code you're looking at so I'll make
the following suggestion completely blind.  You want the header file
which defines smp_nmi_call_function() to contain something like:

#ifdef CONFIG_SMP
extern int smp_nmi_call_function(void (*fn)(void *), void *priv, int whatever);
#else
static inline int smp_nmi_call_function(void (*fn)(void *), void *priv, int 
whatever)
{
return 0;
}
#endif

Obviously I've probably got the arguments to smp_nmi_call_function()
wrong, so they'll need fixing.  I'm sure the above will point you in
the right direction though.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
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.13-rc6-mm1

[Brice Goglin]

Le 19.08.2005 15:27, Russell King a écrit :
> Since you're going to be adding #ifdef CONFIG_SMP...#endif around each
> of these, why not fix where it's declared/defined to be empty?

Probably because I'm too lazy to find a nice way to fix it :)

smp_nmi_call_function may return an error but I don't see any place
where the return value is actually checked. If the error case is
actually possible, we should check the return value, and the warning
would disappear.

Sorry but I'm not familiar enough with this code to know what's the
good solution :(

Regards,
Brice
-
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.13-rc6-mm1

[Russell King]

On Fri, Aug 19, 2005 at 03:25:19PM +0200, Brice Goglin wrote:
> arch/i386/kernel/traps.c: In function 'die_nmi':
> arch/i386/kernel/traps.c:633: warning: statement with no effect
> 
> Another smp_nmi_call.
> 
> Signed-off-by: Brice Goglin <[EMAIL PROTECTED]>

Since you're going to be adding #ifdef CONFIG_SMP...#endif around each
of these, why not fix where it's declared/defined to be empty?

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
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.13-rc6-mm1

[Brice Goglin]

arch/i386/kernel/traps.c: In function 'die_nmi':
arch/i386/kernel/traps.c:633: warning: statement with no effect

Another smp_nmi_call.

Signed-off-by: Brice Goglin <[EMAIL PROTECTED]>

Brice


--- linux-mm/arch/i386/kernel/traps.c.old   2005-08-19 15:19:14.0
+0200
+++ linux-mm/arch/i386/kernel/traps.c   2005-08-19 15:19:47.0 +0200
@@ -630,7 +630,9 @@ void die_nmi (struct pt_regs *regs, cons
printk(" on CPU%d, eip %08lx, registers:\n",
smp_processor_id(), regs->eip);
show_registers(regs);
+#ifdef CONFIG_SMP
smp_nmi_call_function(smp_show_regs, NULL, 1);
+#endif
bust_spinlocks(1);
printk("console shuts up ...\n");
console_silent();

-
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.13-rc6-mm1

[Brice Goglin]

Le 19.08.2005 15:18, Brice Goglin a écrit :
> drivers/char/sysrq.c: In function 'sysrq_handle_showregs':
> drivers/char/sysrq.c:186: warning: statement with no effect
>
> This is caused by a smp call while CONFIG_SMP is not set.
> The attached patch fixes this.

Oops, reverted by mistake. Good one attached.

Signed-off-by: Brice Goglin <[EMAIL PROTECTED]>


--- linux-mm/drivers/char/sysrq.c   2005-08-19 15:15:12.0 +0200
+++ linux-mm/drivers/char/sysrq.c.old   2005-08-19 15:14:53.0 +0200
@@ -182,7 +182,7 @@
if (pt_regs)
show_regs(pt_regs);
bust_spinlocks(0);
+#if defined(__i386__) && defined(CONFIG_SMP)
-#ifdef __i386__
smp_nmi_call_function(smp_show_regs, NULL, 0);
 #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: 2.6.13-rc6-mm1

[Reuben Farrelly]

Hi,

On 19/08/2005 11:33 p.m., Andrew Morton wrote:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc6/2.6.13-rc6-mm1/

- Lots of fixes, updates and cleanups all over the place.

- If you have the right debugging options set, this kernel will generate
  a storm of sleeping-in-atomic-code warnings at boot, from the scsi code.
  It is being worked on.


A few new problems cropped up with this kernel..

1. NFS seems to be unstable, oopsing when shutting down:

Aug 20 12:26:09 tornado shutdown: shutting down for system reboot
Aug 20 12:26:10 tornado init: Switching to runlevel: 6
Aug 20 12:26:10 tornado kernel: Device  not ready.
Aug 20 12:26:10 tornado last message repeated 4 times
Aug 20 12:26:11 tornado smokeping[2524]: Got TERM signal, terminating.
Aug 20 12:26:16 tornado rpc.mountd: Caught signal 15, un-registering and 
exiting.
Aug 20 12:26:20 tornado kernel: [ cut here ]
Aug 20 12:26:20 tornado kernel: kernel BUG at lib/kernel_lock.c:83!
Aug 20 12:26:20 tornado kernel: invalid operand:  [#1]
Aug 20 12:26:20 tornado kernel: SMP
Aug 20 12:26:20 tornado kernel: last sysfs file: 
/devices/pci:00/:00:1d.3/usb5/5-2/5-2.2/5-2.2.1/5-2.2.1.1/5-2.2.1.1:1.1/mod

alias
Aug 20 12:26:20 tornado kernel: Modules linked in: nfsd exportfs lockd eeprom 
sunrpc ipv6 iptable_filter binfmt_misc reiser4 zlib_de
flate zlib_inflate dm_mod video thermal processor fan button ac i8xx_tco 
i2c_i801 sky2 sr_mod

Aug 20 12:26:20 tornado kernel: CPU:1
Aug 20 12:26:20 tornado kernel: EIP:0060:[]Not tainted VLI
Aug 20 12:26:20 tornado kernel: EFLAGS: 00010286   (2.6.13-rc6-mm1)
Aug 20 12:26:20 tornado kernel: EIP is at unlock_kernel+0x28/0x32
Aug 20 12:26:20 tornado kernel: eax:    ebx: 0009   ecx: f6a23f90 
  edx: f6adaa50
Aug 20 12:26:20 tornado kernel: esi: f6a23f54   edi: c191d2fc   ebp: f6b3ffa8 
  esp: f6b3ffa8

Aug 20 12:26:20 tornado kernel: ds: 007b   es: 007b   ss: 0068
Aug 20 12:26:20 tornado kernel: Process nfsd (pid: 2034, threadinfo=f6b3e000 
task=f6adaa50)
Aug 20 12:26:20 tornado kernel: Stack: f6b3ffe4 f8e0e4c2 f8e2d648 f6b3e000 
f6f9103c 00100100 00200200 f6adaa50
Aug 20 12:26:20 tornado kernel:feff  fef8  
f8e0e231   
Aug 20 12:26:20 tornado kernel:c01010b5 f6f9103c   
5a5a5a5a a55a5a5a

Aug 20 12:26:20 tornado kernel: Call Trace:
Aug 20 12:26:20 tornado kernel:  [] show_stack+0x94/0xca
Aug 20 12:26:20 tornado kernel:  [] show_registers+0x15a/0x1ea
Aug 20 12:26:20 tornado kernel:  [] die+0x108/0x183
Aug 20 12:26:20 tornado kernel:  [] do_trap+0x76/0xa1
Aug 20 12:26:20 tornado kernel:  [] do_invalid_op+0x97/0xa1
Aug 20 12:26:20 tornado kernel:  [] error_code+0x4f/0x54
Aug 20 12:26:20 tornado kernel:  [] nfsd+0x291/0x341 [nfsd]
Aug 20 12:26:20 tornado kernel:  [] kernel_thread_helper+0x5/0xb
Aug 20 12:26:20 tornado kernel: Code: 5e 5d c3 55 89 e5 b8 00 e0 ff ff 21 e0 
8b 10 8b 42 14 85 c0 78 15 83 e8 01 89 42 14 85 c0 79 0
9 f0 ff 05 40 e7 36 c0 7e 39 5d c3 <0f> 0b 53 00 37 e1 32 c0 eb e1 8d 05 40 e7 
36 c0 e8 fe dd ff ff

Aug 20 12:26:20 tornado kernel:  [ cut here ]


2.  That message on the third line of the trace above: "kernel: Device  not 
ready." is being logged every few mins or so, I believe it is my SCSI CDROM 
that is causing it.  It also logs something similar after the SCSI driver has 
probed the device on boot:


Aug 20 12:24:36 tornado kernel: scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA 
DRIVER, Rev 7.0

Aug 20 12:24:36 tornado kernel: 
Aug 20 12:24:36 tornado kernel: aic7880: Ultra Wide Channel A, SCSI 
Id=7, 16/253 SCBs

Aug 20 12:24:36 tornado kernel:
Aug 20 12:24:36 tornado kernel:   Vendor: SONY  Model: CD-RW  CRX145S 
Rev: 1.0b
Aug 20 12:24:36 tornado kernel:   Type:   CD-ROM 
ANSI SCSI revision: 04

Aug 20 12:24:36 tornado kernel:  target0:0:6: Beginning Domain Validation
Aug 20 12:24:36 tornado kernel:  target0:0:6: Domain Validation skipping write 
tests
Aug 20 12:24:36 tornado kernel:  target0:0:6: FAST-10 SCSI 10.0 MB/s ST (100 
ns, offset 15)

Aug 20 12:24:36 tornado kernel:  target0:0:6: Ending Domain Validation
Aug 20 12:24:36 tornado kernel: Device  not ready.

This has been a problem for quite a few weeks now, albeit I believe, only a 
cosmetic one.


3. As I have a Marvell Yukon 2 chipset, I was _delighted_ to see a new driver 
from Stephen Hemmingway appear in the netdev tree for it.  However it seems to 
be a bit broken, I get link up and a bit of traffic before it just stops 
passing traffic of any sort and requires an rmmod/modprobe to get going again. 
 I've emailed him directly about this.


4. PAM is complaining about "PAM audit_open() failed: Protocol not suppor
ted" and I can't log in as any user including root.  I would have picked this 
was a userspace problem, but it doesn't break with -rc5-mm1, yet reproduceably 
breaks with -rc

Re: 2.6.13-rc6-mm1

[Brice Goglin]

drivers/char/sysrq.c: In function 'sysrq_handle_showregs':
drivers/char/sysrq.c:186: warning: statement with no effect

This is caused by a smp call while CONFIG_SMP is not set.
The attached patch fixes this.

Signed-off-by: Brice Goglin <[EMAIL PROTECTED]>

Brice


--- linux-mm/drivers/char/sysrq.c.old   2005-08-19 15:14:53.0 +0200
+++ linux-mm/drivers/char/sysrq.c   2005-08-19 15:15:12.0 +0200
@@ -182,7 +182,7 @@ static void sysrq_handle_showregs(int ke
if (pt_regs)
show_regs(pt_regs);
bust_spinlocks(0);
-#if defined(__i386__) && defined(CONFIG_SMP)
+#ifdef __i386__
smp_nmi_call_function(smp_show_regs, NULL, 0);
 #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: 2.6.13-rc6-mm1

[Brice Goglin]

Hi Andrew,

Got this warning:
drivers/char/drm/drm_agpsupport.c:429:5: warning: "LINUX_VERSION_CODE"
is not defined

This test is for old 2.4 code. The attached patch simply removes it.

Signed-off-by: Brice Goglin <[EMAIL PROTECTED]>

Regards,
Brice

--- linux-mm/drivers/char/drm/drm_agpsupport.c.old  2005-08-19
15:07:01.0 +0200
+++ linux-mm/drivers/char/drm/drm_agpsupport.c  2005-08-19
15:07:14.0 +0200
@@ -426,13 +426,8 @@ drm_agp_head_t *drm_agp_init(drm_device_
return NULL;
}
head->memory = NULL;
-#if LINUX_VERSION_CODE <= 0x020408
-   head->cant_use_aperture = 0;
-   head->page_mask = ~(0xfff);
-#else
head->cant_use_aperture = head->agp_info.cant_use_aperture;
head->page_mask = head->agp_info.page_mask;
-#endif

return 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/

2.6.13-rc6-mm1

[Andrew Morton]

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc6/2.6.13-rc6-mm1/

- Lots of fixes, updates and cleanups all over the place.

- If you have the right debugging options set, this kernel will generate
  a storm of sleeping-in-atomic-code warnings at boot, from the scsi code.
  It is being worked on.


Changes since 2.6.13-rc5-mm1:

 linus.patch
 git-acpi.patch
 git-acpi-ia64-fixes.patch
 git-alsa.patch
 git-cpufreq.patch
 git-cryptodev.patch
 git-drm.patch
 git-ia64.patch
 git-audit.patch
 git-input.patch
 git-kbuild.patch
 git-libata-all.patch
 git-mtd.patch
 git-netdev-all.patch
 git-net.patch
 git-ocfs2.patch
 git-serial.patch
 git-scsi-block.patch
 git-scsi-iscsi.patch
 git-scsi-iscsi-vs-git-net.patch
 git-net-vs-iscsi-fix.patch
 git-scsi-misc.patch
 git-watchdog.patch

 Subsystem trees

-x86_64-ignore-machine-checks-from-boot-time.patch
-__bio_clone-dead-comment.patch
-make-visws-compile-again.patch
-visws-linkage-fix.patch
-remove-linux-pagemaph-from-linux-swaph.patch
-namespacec-fix-bind-mount-from-foreign-namespace.patch
-8xx-convert-fec-driver-to-use-work_struct.patch
-8xx-using-dma_alloc_coherent-instead-consistent_alloc.patch
-8xx-fec-fix-interrupt-handler-prototypes.patch
-ppc32-8xx-fix-cpm-ethernet-description.patch
-ppc32-8xx-restrict-enet_big_buffers-option.patch
-ppc32-8xx-kill-unused-variable-in-commproc.patch
-ppc32-8xx-commproc-avoid-direct-pte-manipulation-use-dma-coherent-api-instead.patch
-move-the-fix-to-align-node_end_pfns-to-a-proper-location.patch
-crc32c-typo-fix.patch
-acpi-videoc-properly-remove-notify-handlers.patch
-ns558-list-handling-fix.patch
-git-net-ddcp-fixes.patch
-git-net-svcsock-build-fix.patch
-time-conversion-error-in-net-sunrpc-svcsockc.patch
-aic79xx-needs-scsi_transport_spi.patch
-i6300esb-pci_match_device-fix.patch
-s2io-fix-a-compiler-warning-in-a-printk.patch
-s390-use-klist-in-qeth-driver.patch
-new-driver-for-yealink-usb-p1k-phone.patch
-new-driver-for-yealink-usb-p1k-phone-endianness-fix.patch
-kconfig-trivial-cleanup.patch
-xdr-input-validation.patch
-nfs-split-nfsi-flags-into-two-fields.patch
-nfs-use-atomic-bitops-to-manipulate-flags-in-nfsi-flags.patch
-nfs-introduce-the-use-of-inode-i_lock-to-protect-fields-in-nfsi.patch
-fbdev-dont-allow-softcursor-use-from-userland.patch
-fbdev-mach64-atari-patch.patch
-fbsysfs-remove-casts-from-void.patch
-drivers-char-ip2-i2libc-replace-direct-assignment-with-set_current_state.patch
-ide-add-support-for-netcell-revolution-to-pci-ide-generic-driver.patch

 Merged

+tpm_infineon-bugfix-in-pnpacpi-handling.patch

 TPM driver fix

+mobil-pentium-4-ht-and-the-nmi.patch

 Mobile P4 NMI fix

+move-truncate_inode_pages-into-delete_inode.patch
+update-filesystems-for-new-delete_inode-behavior.patch

 Broken out of the OCFS2 patch

+git-acpi-ia64-fixes.patch

 Fix ACPI-vs-ia64

+gregkh-driver-driver-docs-whitespace.patch
+gregkh-driver-driver-docs-permissions.patch
+gregkh-driver-driver-handle-sysdev-suspend-failure.patch
+gregkh-driver-sysfs-strip_leading_trailing_whitespace.patch

 Additions to Greg's driver tree

+seclvl-use-securityfs.patch
+seclvl-use-securityfs-tidy.patch
+seclvl-use-securityfs-fix.patch

 Convert seclvl to use securityfs

+gregkh-i2c-i2c-inline-i2c_adapter_id.patch
+gregkh-i2c-i2c-i2c-algo-pca-busy-bus-fix.patch
+gregkh-i2c-i2c-documentation-typo.patch
+gregkh-i2c-i2c-core-debug-cleanup.patch
+gregkh-i2c-hwmon-move-SENSORS_LIMIT.patch
+gregkh-i2c-hwmon-lm85-cleanups.patch
+gregkh-i2c-hwmon-split-round2-01.patch
+gregkh-i2c-hwmon-split-round2-02.patch
+gregkh-i2c-hwmon-split-round2-03.patch
+gregkh-i2c-hwmon-split-round2-04.patch
+gregkh-i2c-hwmon-split-round2-05.patch
+gregkh-i2c-hwmon-split-round2-06.patch
+gregkh-i2c-hwmon-split-round2-07.patch
+gregkh-i2c-hwmon-split-round2-08.patch
+gregkh-i2c-hwmon-split-round2-09.patch
+gregkh-i2c-hwmon-split-round2-10.patch
+gregkh-i2c-hwmon-split-round2-11.patch
+gregkh-i2c-hwmon-vid-table-update.patch
+gregkh-i2c-i2c-rewrite-i2c_probe.patch
+gregkh-i2c-i2c-centralize-24rf08-corruption-prevention.patch
+gregkh-i2c-i2c-kill-i2c_algorithm-stuff-01.patch
+gregkh-i2c-i2c-kill-i2c_algorithm-stuff-02.patch
+gregkh-i2c-i2c-kill-i2c_algorithm-stuff-03.patch
+gregkh-i2c-i2c-kill-i2c_algorithm-stuff-04.patch
+gregkh-i2c-i2c-kill-i2c_algorithm-stuff-05.patch
+gregkh-i2c-i2c-kill-i2c_algorithm-stuff-06.patch
+gregkh-i2c-i2c-kill-i2c_algorithm-stuff-07.patch
+gregkh-i2c-i2c-outdated-i2c_adapter-comment.patch
+gregkh-i2c-hwmon-maintainer.patch
+gregkh-i2c-i2c-drop-i2c_clientname.patch
+gregkh-i2c-w1-changed_default_netlink_group.patch
+gregkh-i2c-w1-fs9490-sync.patch
+gregkh-i2c-w1-01-hotplug.patch
+gregkh-i2c-w1-02-64bit.patch
+gregkh-i2c-w1-03.patch
+gregkh-i2c-w1-04.patch
+gregkh-i2c-w1-05.patch
+gregkh-i2c-w1-06.patch
+gregkh-i2c-w1-07.patch
+gregkh-i2c-w1-08.patch
+gregkh-i2c-w1-09.patch

 i2c tree

+kbuild-fix-make-clean-damaging-hg-repos.patch

 kbuild fix for Mercurial

-git-libata-adma-mwi.patch
-git-libata-chs-support.patch
-git-l