Re: 2.5.62 oops and Raid-5

Re: 2.5.62 oops and Raid-5

[Stef Telford]

Ah, silly me, should have done that in the first place.
apologies.


----

Unable to handle kernel NULL pointer dereference at virtual address 00000000
 00000000
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0060:[<00000000>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010046
eax: 00000000   ebx: cfd904ac   ecx: cfd905d0   edx: 00000000
esi: cffe8880   edi: cfd90584   ebp: c12ba000   esp: c12bbf4c
ds: 007b   es: 007b   ss: 0068
Stack: c0267f47 cfd904ac cfd90588 c012c403 cfd904ac cffe8884 c12ba000 cfd904ac
       c0267f50 cffe8884 cffe8880 c1299fa8 cffe888c c012c078 cffe8880 c12bbfa0
       00000000 00000000 c12ba000 c12ba000 c12ba000 00000001 00000000 c0119fd0
Call Trace: [<c0267f47>]  [<c012c403>]  [<c0267f50>]  [<c012c078>]  [<c0119fd0>]  [<c0119fd0>]  [<c012beb0>]  [<c0108d39>]
Code:  Bad EIP value.
 
 
>>EIP; 00000000 Before first symbol
 
>>ebx; cfd904ac <__crc_isapnp_read_dword+199265/34390f>
>>ecx; cfd905d0 <__crc_isapnp_read_dword+199389/34390f>
>>esi; cffe8880 <__crc_ip_cmsg_recv+6ff9f/15d343>
>>edi; cfd90584 <__crc_isapnp_read_dword+19933d/34390f>
>>ebp; c12ba000 <__crc_memcpy_tokerneliovec+5bf78/23058d>
>>esp; c12bbf4c <__crc_memcpy_tokerneliovec+5dec4/23058d>
 
Trace; c0267f47 <generic_unplug_device+77/80>
Trace; c012c403 <run_workqueue+73/e0>
Trace; c0267f50 <blk_unplug_work+0/10>
Trace; c012c078 <worker_thread+1c8/200>
Trace; c0119fd0 <default_wake_function+0/20>
Trace; c0119fd0 <default_wake_function+0/20>
Trace; c012beb0 <worker_thread+0/200>
Trace; c0108d39 <kernel_thread_helper+5/c>


----

Re: 2.5.62 oops and Raid-5

[Neil Brown]

On Monday February 17, stef@chronozon.artofdns.com wrote:
> Ah, silly me, should have done that in the first place.
> apologies.
> 

>  
> Trace; c0267f47 <generic_unplug_device+77/80>
> Trace; c012c403 <run_workqueue+73/e0>
> Trace; c0267f50 <blk_unplug_work+0/10>
> Trace; c012c078 <worker_thread+1c8/200>
> Trace; c0119fd0 <default_wake_function+0/20>
> Trace; c0119fd0 <default_wake_function+0/20>
> Trace; c012beb0 <worker_thread+0/200>
> Trace; c0108d39 <kernel_thread_helper+5/c>
> 
Hmm... I cannot see how recent changes would have affected this, but
does the following patch help?

Thanks,
NeilBrown



 ----------- Diffstat output ------------
 ./drivers/block/ll_rw_blk.c |    2 ++
 1 files changed, 2 insertions(+)

diff ./drivers/block/ll_rw_blk.c~current~ ./drivers/block/ll_rw_blk.c
--- ./drivers/block/ll_rw_blk.c~current~	2003-02-18 16:38:49.000000000 +1100
+++ ./drivers/block/ll_rw_blk.c	2003-02-18 16:38:57.000000000 +1100
@@ -240,6 +240,8 @@ void blk_queue_make_request(request_queu
 	blk_queue_hardsect_size(q, 512);
 	blk_queue_dma_alignment(q, 511);
 
+	INIT_LIST_HEAD(&q->queue_head);
+
 	q->unplug_thresh = 4;		/* hmm */
 	q->unplug_delay = (3 * HZ) / 1000;	/* 3 milliseconds */
 	if (q->unplug_delay == 0)

Re: 2.5.62 oops and Raid-5

[Stef Telford]

Neil wrote:
> Hmm... I cannot see how recent changes would have affected this, but
> does the following patch help?

actually, believe it or not but the patch made things
worse ?! that being said, i removed isapnp (as that 
was also mentioned in one of the symoops) and the
oops on mount went away. Notice that the oops on
mount didnt stop the raid5 from being mounted
and accessible, jst it was annoying to see
an oops on mount. I can understand the 
hotplug causing problems with raid (sudden
appearance of an entire 240gig raid5 disk
could cause hotplug to 'fire events' :) but
isapnp ? very curious indeed.

This of course means that i cant use my isa NIC, but
i can live without it. so no problem there.

one last thing that i noticed going from 2.5.58 to
2.5.62, if i do a cat /proc/mdstat it will stop at
around md198 (from md255 down to and including md198)
and the syslog will generate this error:

Feb 19 14:48:50 survivor kernel: proc_file_read: Apparent buffer
overflow!

This isnt really a 'major problem' for me, and i should
point out that even though md0 is mounted, it is currently
in degraded status and is being rebuilt. Incase that
makes any difference (jst in case ;)

regards
Stef

Re: 2.5.62 oops and Raid-5

[Stef Telford]

actually, whilst i was sending you the ksymoops output
i searched and googled a bit and saw that hotplug seems
to crop up more than once in conjunction with the 
worker_thread 'oops'. I disabled that and recompiled 
(its an athlon, so it doesnt take long), re-lilo'd and
booted the 'new kernel'. This was the only kernel parameter
i changed and now i can mount the raid5 and it is marked
'clean' after the rebuild. i am currently using it as
well, playing mp3's from it, so its looking good.

that being said, there -was- a symoops on mount, although
it wasnt enough to stop it from mounting, and it appears
to be the same as the last one (same sort of ksymoops
output :\

i will try the patch tomorrow and let you know, i am
jst glad that the drive is working (for now :)

thanks for the help 
Stef

2.5.62 oops and Raid-5

[Stef Telford]

Hello,
        sorry to be a pain, but for some reason I
am getting a symoops under 2.5.62, yet everything
works fine in 2.5.58 (although i notice reiserfs
corruption in that one. not good)
 
        The symoops only comes after the raid-5 has
finished rebuilding, or if i try to mount it whilst
its still in degraded mode/rebuilding. either way,
it crashes.
 
md: md0: sync done.
RAID5 conf printout:
 --- rd:4 wd:4 fd:0
 disk 0, o:1, dev:ide/host2/bus0/target0/lun0/part6
 disk 1, o:1, dev:ide/host2/bus1/target0/lun0/part1
 disk 2, o:1, dev:ide/host4/bus0/target0/lun0/part6
 disk 3, o:1, dev:ide/host4/bus1/target0/lun0/part1
md: updating md0 RAID superblock on device
md: ide/host4/bus1/target0/lun0/part1 <6>(write) ide/host4/bus1/target0/lun0/part1's sb offset: 58633216
md: ide/host4/bus0/target0/lun0/part6 <6>(write) ide/host4/bus0/target0/lun0/part6's sb offset: 58633728
md: ide/host2/bus1/target0/lun0/part1 <6>(write) ide/host2/bus1/target0/lun0/part1's sb offset: 58633216
md: ide/host2/bus0/target0/lun0/part6 <6>(write) ide/host2/bus0/target0/lun0/part6's sb offset: 58633728
Unable to handle kernel NULL pointer dereference at virtual address 00000000
 printing eip:
00000000
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0060:[<00000000>]    Not tainted
EFLAGS: 00010046
eax: 00000000   ebx: cfd904ac   ecx: cfd905d0   edx: 00000000
esi: cffe8880   edi: cfd90584   ebp: c12ba000   esp: c12bbf4c
ds: 007b   es: 007b   ss: 0068
Process events/0 (pid: 3, threadinfo=c12ba000 task=c12bec40)
Stack: c0267f47 cfd904ac cfd90588 c012c403 cfd904ac cffe8884 c12ba000 cfd904ac
       c0267f50 cffe8884 cffe8880 c1299fa8 cffe888c c012c078 cffe8880 c12bbfa0
       00000000 00000000 c12ba000 c12ba000 c12ba000 00000001 00000000 c0119fd0
Call Trace: [<c0267f47>]  [<c012c403>]  [<c0267f50>]  [<c012c078>]  [<c0119fd0>]  [<c0119fd0>]  [<c012beb0>]  [<c0108d39>]
Code:  Bad EIP value.
 <6>note: events/0[3] exited with preempt_count 1

 
If there is anything else that may be of use,
jst let me know and i will forward that as well.
 
Thanks
Stef.

Re: 2.5.62 oops and Raid-5

[Neil Brown]

On Monday February 17, stef@chronozon.artofdns.com wrote:
> Hello,
>         sorry to be a pain, but for some reason I
> am getting a symoops under 2.5.62, yet everything
> works fine in 2.5.58 (although i notice reiserfs
> corruption in that one. not good)
>  
>         The symoops only comes after the raid-5 has
> finished rebuilding, or if i try to mount it whilst
> its still in degraded mode/rebuilding. either way,
> it crashes.
>  
> md: md0: sync done.
> RAID5 conf printout:
>  --- rd:4 wd:4 fd:0
>  disk 0, o:1, dev:ide/host2/bus0/target0/lun0/part6
>  disk 1, o:1, dev:ide/host2/bus1/target0/lun0/part1
>  disk 2, o:1, dev:ide/host4/bus0/target0/lun0/part6
>  disk 3, o:1, dev:ide/host4/bus1/target0/lun0/part1
> md: updating md0 RAID superblock on device
> md: ide/host4/bus1/target0/lun0/part1 <6>(write) ide/host4/bus1/target0/lun0/part1's sb offset: 58633216
> md: ide/host4/bus0/target0/lun0/part6 <6>(write) ide/host4/bus0/target0/lun0/part6's sb offset: 58633728
> md: ide/host2/bus1/target0/lun0/part1 <6>(write) ide/host2/bus1/target0/lun0/part1's sb offset: 58633216
> md: ide/host2/bus0/target0/lun0/part6 <6>(write) ide/host2/bus0/target0/lun0/part6's sb offset: 58633728
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
>  printing eip:
> 00000000
> *pde = 00000000
> Oops: 0000
> CPU:    0
> EIP:    0060:[<00000000>]    Not tainted
> EFLAGS: 00010046
> eax: 00000000   ebx: cfd904ac   ecx: cfd905d0   edx: 00000000
> esi: cffe8880   edi: cfd90584   ebp: c12ba000   esp: c12bbf4c
> ds: 007b   es: 007b   ss: 0068
> Process events/0 (pid: 3, threadinfo=c12ba000 task=c12bec40)
> Stack: c0267f47 cfd904ac cfd90588 c012c403 cfd904ac cffe8884 c12ba000 cfd904ac
>        c0267f50 cffe8884 cffe8880 c1299fa8 cffe888c c012c078 cffe8880 c12bbfa0
>        00000000 00000000 c12ba000 c12ba000 c12ba000 00000001 00000000 c0119fd0
> Call Trace: [<c0267f47>]  [<c012c403>]  [<c0267f50>]  [<c012c078>]  [<c0119fd0>]  [<c0119fd0>]  [<c012beb0>]  [<c0108d39>]
> Code:  Bad EIP value.
>  <6>note: events/0[3] exited with preempt_count 1
> 
>  
> If there is anything else that may be of use,
> jst let me know and i will forward that as well.

Well,  if you could decode the oops with ksymoops, that would help a
lot.

NeilBrown

>  
> Thanks
> Stef.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html