[OOPS] report

[OOPS] report

[David]

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!
Mar 15 18:02:49 Huntington-Beach kernel: invalid operand: 0000
Mar 15 18:02:49 Huntington-Beach kernel: CPU:    0
Mar 15 18:02:49 Huntington-Beach kernel: EIP:    
0010:[reiserfs_panic+357/440]
Mar 15 18:02:49 Huntington-Beach kernel: EFLAGS: 00010282
Mar 15 18:02:49 Huntington-Beach kernel: eax: 0000001c   ebx: c0420e40   
ecx: cf190000   edx: c03a4008
Mar 15 18:02:49 Huntington-Beach kernel: esi: c39a5ecc   edi: c39a5ebc   
ebp: 00000000   esp: c39a5e90
Mar 15 18:02:49 Huntington-Beach kernel: ds: 0018   es: 0018   ss: 0018
Mar 15 18:02:49 Huntington-Beach kernel: Process sync (pid: 30559, 
stackpage=c39a5000)
Mar 15 18:02:49 Huntington-Beach kernel: Stack: c031a785 c031aa74 
0000014c d1526154 00000002 00000000 cfeb0c00 c0421240
Mar 15 18:02:49 Huntington-Beach kernel:        c39a5ebc c39a5eb8 
c39a4000 00000000 c0193a6f cfeb0c00 c031cd20 00000002
Mar 15 18:02:49 Huntington-Beach kernel:        00000012 00000010 
00000000 d1526188 d152617c 00000003 00000000 00000003
Mar 15 18:02:49 Huntington-Beach kernel: Call Trace: [<d1526154>] 
[flush_commit_list+659/908] [<d1526188>] [<d152617c>] 
[do_journal_end+1935/2652] [<d1526154>] [<d1543000>]
Mar 15 18:02:50 Huntington-Beach kernel:        
[flush_old_commits+391/420] [reiserfs_write_super+21/32] 
[sync_supers+118/172] [fsync_dev+23/48] [sys_sync+7/16] [system_call+51/56]
Mar 15 18:02:50 Huntington-Beach kernel:
Mar 15 18:02:50 Huntington-Beach kernel: Code: 0f 0b 83 c4 0c 83 7c 24 
28 00 74 17 8b 7c 24 28 80 7f 11 00

Re: [OOPS] report

[Alexander Viro]

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

Re: [OOPS] report

[Chris Mason]

On Thursday, March 15, 2001 09:44:48 PM -0500 Alexander Viro
<viro@math.psu.edu> 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

Re: [OOPS] report

[Alexander Viro]

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()...

Re: [OOPS] report

[Chris Mason]

On Friday, March 16, 2001 12:32:56 AM -0500 Alexander Viro
<viro@math.psu.edu> 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

Re: [OOPS] report

[Alexander Viro]

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.

Re: [OOPS] report

[Chris Mason]

On Friday, March 16, 2001 01:03:20 AM -0500 Alexander Viro
<viro@math.psu.edu> 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