2.4.1-pre7 raid5syncd oops

2.4.1-pre7 raid5syncd oops

[junio]

Unable to handle kernel NULL pointer dereference at virtual address 00000003
c01ccf91
*pde = 00000000
Oops: 0002
CPU:    0
EIP:    0010:[<c01ccf91>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010086
eax: ffffffff   ebx: c1490400   ecx: cfdeb000   edx: cfeed13c
esi: cfdeb000   edi: 00001e29   ebp: 00000013   esp: cfba7e80
ds: 0018   es: 0018   ss: 0018
Process raid5syncd (pid: 9, stackpage=cfba7000)
Stack: c01ccfe0 cfdeb000 c1490400 00000000 c01cd430 c1490400 c1490400 0003c53c 
       00001e29 00000013 00000000 00000000 cfba6000 00001000 00000000 00000000 
       00000000 c1490400 c01cf2a8 c1490400 00078a78 00000000 00000000 cfba6000 
Call Trace: [<c01ccfe0>] [<c01cd430>] [<c01cf2a8>] [<c01d708b>] [<c01cf40f>] [<c01d63cd>] [<c01074b8>] 
Code: 89 50 04 8b 51 04 8b 01 89 02 c7 41 04 00 00 00 00 c3 8d b6 

>>EIP; c01ccf91 <remove_hash+11/30>   <=====
Trace; c01ccfe0 <get_free_stripe+30/50>
Trace; c01cd430 <get_active_stripe+260/520>
Trace; c01cf2a8 <raid5_sync_request+48/e0>
Trace; c01d708b <md_do_sync+1fb/470>
Trace; c01cf40f <raid5syncd+2f/70>
Trace; c01d63cd <md_thread+fd/170>
Trace; c01074b8 <kernel_thread+28/40>
Code;  c01ccf91 <remove_hash+11/30>
00000000 <_EIP>:
Code;  c01ccf91 <remove_hash+11/30>   <=====
   0:   89 50 04                  mov    %edx,0x4(%eax)   <=====
Code;  c01ccf94 <remove_hash+14/30>
   3:   8b 51 04                  mov    0x4(%ecx),%edx
Code;  c01ccf97 <remove_hash+17/30>
   6:   8b 01                     mov    (%ecx),%eax
Code;  c01ccf99 <remove_hash+19/30>
   8:   89 02                     mov    %eax,(%edx)
Code;  c01ccf9b <remove_hash+1b/30>
   a:   c7 41 04 00 00 00 00      movl   $0x0,0x4(%ecx)
Code;  c01ccfa2 <remove_hash+22/30>
  11:   c3                        ret    
Code;  c01ccfa3 <remove_hash+23/30>
  12:   8d b6 00 00 00 00         lea    0x0(%esi),%esi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre7 raid5syncd oops

[Neil Brown]

On  January 16, junio@siamese.dhis.twinsun.com wrote:
> 
> Unable to handle kernel NULL pointer dereference at virtual address 00000003
> c01ccf91
> *pde = 00000000
> Oops: 0002
> CPU:    0
> EIP:    0010:[<c01ccf91>]
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010086
> eax: ffffffff   ebx: c1490400   ecx: cfdeb000   edx: cfeed13c
> esi: cfdeb000   edi: 00001e29   ebp: 00000013   esp: cfba7e80
> ds: 0018   es: 0018   ss: 0018
> Process raid5syncd (pid: 9, stackpage=cfba7000)
> Stack: c01ccfe0 cfdeb000 c1490400 00000000 c01cd430 c1490400 c1490400 0003c53c 
>        00001e29 00000013 00000000 00000000 cfba6000 00001000 00000000 00000000 
>        00000000 c1490400 c01cf2a8 c1490400 00078a78 00000000 00000000 cfba6000 
> Call Trace: [<c01ccfe0>] [<c01cd430>] [<c01cf2a8>] [<c01d708b>] [<c01cf40f>] [<c01d63cd>] [<c01074b8>] 
> Code: 89 50 04 8b 51 04 8b 01 89 02 c7 41 04 00 00 00 00 c3 8d b6 
> 
> >>EIP; c01ccf91 <remove_hash+11/30>   <=====
> Trace; c01ccfe0 <get_free_stripe+30/50>
....

This is really odd.
It looks like sh->hash_next == -1.
But, sh->hash_next is only ever set from
   ->hash_next for some other sh, by the line
		*sh->hash_pprev = sh->hash_next;
in remove_hash, or to an entry from the stripe_hashtbl array.
and stripe_hashtbl[] is only ever set to the address of a stripe_head,
or to the value of a sh->hash_next, or to zero at initialisation.

Or in short "this cannot happen" :-)

Is there any chance of a memory error?

Has this happened more than once?

NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre7 raid5syncd oops

[junio]

>>>>> "NB" == Neil Brown <neilb@cse.unsw.edu.au> writes:

NB> On  January 16, junio@siamese.dhis.twinsun.com wrote:

NB> Or in short "this cannot happen" :-)

NB> Is there any chance of a memory error?

NB> Has this happened more than once?

I have to confess that I was not running with the stock
2.4.1-pre7 drivers/md/raid5.c; instead I compiled it with the
change in -ac9 tree, which checks the return value of
alloc_page() early (around line 160).  Also I had your ``Desk
check'' patch (responding to mtew@cds.duke.edu's post) from
linux-raid list (around line 1075), and mingo's
hot-add/hot-remove fixes.

The symptom was very reproducible with that particular kernel
(essentially, early in the every reboot sequence I got the same
error).  In the end, I had to futz with partition type to
disable autodetection of those offending raid-5 component
partitions to recover from the failure.  Since then I reverted
back to the stock 2.4.1-pre7 driver with only the ``Desk check''
and mingo's hot-add/hot-remove patch, and have not seen the
problem again.  It appears that using those early-null-check
code from -ac9 without understanding its implications was purely
my stupidity, but I still do not offhand see why that would
hurt...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/