Re: Oops report for the week upto Feb 10th 2008
Alexey Dobriyan wrote: On Sun, Feb 10, 2008 at 04:35:51PM -0800, Arjan van de Ven wrote: Rank 3: remove_proc_entry WARN_ON at fs/proc/generic.c:736 Reported 20 times (38 total reports) This WARN_ON is there if code tries to remove a non-empty /proc directory. Most reports are tainted, pointing at a bug in a binary module. Without the WARN_ON improvements from 2.6.25-rc1 it'll be hard to figure out which module is guilty. Easy, I'll submit patch RSN. to fix it or to print modules? (the later is already done in 2.6.25-rc1, just not in 2.6.24 yet) -- 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: Oops report for the week upto Feb 10th 2008
On Sun, Feb 10, 2008 at 04:35:51PM -0800, Arjan van de Ven wrote: > Rank 3: remove_proc_entry > WARN_ON at fs/proc/generic.c:736 > Reported 20 times (38 total reports) > This WARN_ON is there if code tries to remove a non-empty /proc > directory. > Most reports are tainted, pointing at a bug in a binary module. > Without the WARN_ON improvements from 2.6.25-rc1 it'll be hard to > figure out which module is guilty. Easy, I'll submit patch RSN. -- 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: Oops report for the week upto Feb 10th 2008
On Monday 11 February 2008 11:35, Arjan van de Ven wrote: > The http://www.kerneloops.org website collects kernel oops and > warning reports from various mailing lists and bugzillas as well as > with a client users can install to auto-submit oopses. > Below is a top 10 list of the oopses/backtraces collected in the last 7 > days. (Reports prior to 2.6.23 have been omitted in collecting the top 10) > > This week, a total of 323 oopses and warnings have been reported, > compared to 110 reports in the previous week. > > (This sharp increase is due to Fedora 9 alpha shipping the oops data > collection client in the default install, giving us much wider coverage > in the issues that actual users hit; many thanks to the Fedora project > for this) > > With the 2.6.25-rc1 release out, this will be the last report that includes > 2.6.23; future reports will only include issues from 2.6.24 and later. > > > Rank 1: set_dentry_child_flags > WARN_ON at fs/inotify.c:172 set_dentry_child_flags > Reported 93 times (116 total reports) > This is a user triggered WARN_ON in inotify. Sadly inotify seems to be > unmaintained. More info: > http://www.kerneloops.org/search.php?search=set_dentry_child_flags I was never able to trigger this or get anyone to reliably trigger it with a debug patch in. Which is why it has taken so long to fix. It looks like kde4 is triggering this big rash of new reports. Anyway, I have fixed a race or two and removed that warning code (which was also a little racy). So I think that should be OK. > Rank 9: mark_buffer_dirty > WARN_ON at fs/buffer.c:1169 > This indicates that a non-uptodate buffer is marked dirty. > This can lead to data corruption! > Reported 5 times (12 total reports) - Only seen since 2.6.24-rc6 > Usually happens during umount() > More info: http://www.kerneloops.org/search.php?search=mark_buffer_dirty That's interesting. -- 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: [OOPS] report
On Friday, March 16, 2001 01:03:20 AM -0500 Alexander Viro <[EMAIL PROTECTED]> wrote: >> Ok, I was more talking about the ugliness that is reiserfs_panic (how >> many times do we need a commented out for(;;)?). For panic() calling >> sys_sync, I think there non-filesystem related panics where we do want >> to sync. > > panic doesn't sync if called from interrupt (thanks $DEITY). > It is pointless to sync during boot. > sync from driver panic is not better than one from fs. > > What does it leave? I hadn't checked each panic(), but it seems that > if we ever want syncing upon panic() it's safer to do sys_sync() by > hands before calling panic(). If it is actually ever needed, that is. > > A quick grep -r shows over 700 panic callers (outside reiserfs). Most look like init messages, or things that generally happen during interrupts. But, I think there are too many to assume that nobody could benefit from a sync. Does that mean they _need_ the sync? Probably not. -chris - 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: [OOPS] report
On Fri, 16 Mar 2001, Chris Mason wrote: > > I suspect that the right fix is to drop the ->s_lock bogosity along with > > sys_sync() call in panic()... > > Ok, I was more talking about the ugliness that is reiserfs_panic (how many > times do we need a commented out for(;;)?). For panic() calling sys_sync, > I think there non-filesystem related panics where we do want to sync. panic doesn't sync if called from interrupt (thanks $DEITY). It is pointless to sync during boot. sync from driver panic is not better than one from fs. What does it leave? I hadn't checked each panic(), but it seems that if we ever want syncing upon panic() it's safer to do sys_sync() by hands before calling panic(). If it is actually ever needed, that is. - 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: [OOPS] report
On Friday, March 16, 2001 12:32:56 AM -0500 Alexander Viro <[EMAIL PROTECTED]> wrote: > > > On Fri, 16 Mar 2001, Chris Mason wrote: > >> > ObReiserfs_panic: what the hell is that ->s_lock bit about? panic() >> > _never_ tries to do any block IO. It looks like a rudiment of something >> > that hadn't been there for 5 years, if not longer. The same goes for >> > ext2_panic() and ufs_panic(), BTW... I would suggest crapectomey here. >> >> Ugh, that should have been dragged out and shot...patch will come in the >> AM. >> > Unfortunately it's nastier than I thought. panic() does sys_sync(). And > IMO it really shouldn't. Notice that ->s_lock doesn't prevent > ->write_inode() and friends from being called. > > I suspect that the right fix is to drop the ->s_lock bogosity along with > sys_sync() call in panic()... Ok, I was more talking about the ugliness that is reiserfs_panic (how many times do we need a commented out for(;;)?). For panic() calling sys_sync, I think there non-filesystem related panics where we do want to sync. -chris - 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: [OOPS] report
On Thursday, March 15, 2001 09:44:48 PM -0500 Alexander Viro
<[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 15 Mar 2001, David wrote:
>
>> 2.4.2-ac4
>>
>> Mar 15 18:02:49 Huntington-Beach kernel: end_request: I/O error, dev
>> 16:41 (hdd), sector 9512
>> Mar 15 18:02:49 Huntington-Beach kernel: hdd: drive not ready for command
>> Mar 15 18:02:48 Huntington-Beach kernel: hdd: drive not ready for command
>> Mar 15 18:02:49 Huntington-Beach kernel: hdd: status error: status=0x00
>> { } Mar 15 18:02:49 Huntington-Beach kernel: hdd: drive not ready for
>> command Mar 15 18:02:49 Huntington-Beach kernel: journal-601, buffer
>> write failed Mar 15 18:02:49 Huntington-Beach kernel: kernel BUG at
>> prints.c:332!
>
> Umm... Chris, I really don't think that panic() (or BUG(), for that
> matter) is an appropriate reaction to IO errors. They are expected
> events, after all...
>
Nods. It needs to force a readonly mount instead.
> ObReiserfs_panic: what the hell is that ->s_lock bit about? panic()
> _never_ tries to do any block IO. It looks like a rudiment of something
> that hadn't been there for 5 years, if not longer. The same goes for
> ext2_panic() and ufs_panic(), BTW... I would suggest crapectomey here.
Ugh, that should have been dragged out and shot...patch will come in the AM.
-chris
-
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: [OOPS] report
On Fri, 16 Mar 2001, Chris Mason wrote: > > ObReiserfs_panic: what the hell is that ->s_lock bit about? panic() > > _never_ tries to do any block IO. It looks like a rudiment of something > > that hadn't been there for 5 years, if not longer. The same goes for > > ext2_panic() and ufs_panic(), BTW... I would suggest crapectomey here. > > Ugh, that should have been dragged out and shot...patch will come in the AM. > Unfortunately it's nastier than I thought. panic() does sys_sync(). And IMO it really shouldn't. Notice that ->s_lock doesn't prevent ->write_inode() and friends from being called. I suspect that the right fix is to drop the ->s_lock bogosity along with sys_sync() call in panic()... - 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: [OOPS] report
On Thu, 15 Mar 2001, David wrote:
> 2.4.2-ac4
>
> Mar 15 18:02:49 Huntington-Beach kernel: end_request: I/O error, dev
> 16:41 (hdd), sector 9512
> Mar 15 18:02:49 Huntington-Beach kernel: hdd: drive not ready for command
> Mar 15 18:02:48 Huntington-Beach kernel: hdd: drive not ready for command
> Mar 15 18:02:49 Huntington-Beach kernel: hdd: status error: status=0x00 { }
> Mar 15 18:02:49 Huntington-Beach kernel: hdd: drive not ready for command
> Mar 15 18:02:49 Huntington-Beach kernel: journal-601, buffer write failed
> Mar 15 18:02:49 Huntington-Beach kernel: kernel BUG at prints.c:332!
Umm... Chris, I really don't think that panic() (or BUG(), for that matter)
is an appropriate reaction to IO errors. They are expected events, after
all...
ObReiserfs_panic: what the hell is that ->s_lock bit about? panic() _never_
tries to do any block IO. It looks like a rudiment of something that hadn't
been there for 5 years, if not longer. The same goes for ext2_panic() and
ufs_panic(), BTW... I would suggest crapectomey here.
Cheers,
Al
-
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: OOPS REPORT: Will someone _please_ look at this? (was Re: BUG & OOPS REPORT: /proc/scsi/ entries not properly cleaned up)
Matthew Dharm wrote: > > Yet more followup with myself I can reproduce this problem on > 2.4.0-test10-pre1 every time. I'm using the ide-scsi and usb-storage > modules to trigger the bug -- loading and then unloading either one causes > /proc/scsi to not be cleaned up properly. > > As yet, nobody has indicated to me that they are looking into this problem. > I've taken a few experimental pokes at it, and it seems that the SCSI layer > is, in fact, calling the procfs function to remove the entries. At least, > I think it is -- I'm not sure if it's the right entry. > > Will someone _please_ look at this? I consider this a critical item for > 2.4.0, and I hope others do too. Matt, Well I looked at it on the weekend and didn't see anything. Unfortunately I don't have any USB devices or IDE cdroms in the right place to replicate your configuration. I guess the problem revolves around calling remove_proc_entry() with the appropriate arguments bottom up for the subtree you wish to delete from procfs. One way that I have noticed that you can see that remove_proc_entry() is working is to place the cwd in a procfs directory belonging to driver you are about to rmmod. [For example: 'cd /proc/scsi/sg ; rmmod sg']. When the rmmod is done the kernel spits out a message like: remove_proc_entry: scsi/sg busy, count=1 When I back out of that directory the kernel outputs: de_put: deferred delete of sg Hope this helps. Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
