Re: 2.5.62 oops and Raid-5

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)

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