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