lkml.org 
[lkml]   [2000]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: 2.4.0-test10-pre3 Ooops
On Wed, 18 Oct 2000, Mike Galbraith wrote:

> On Wed, 18 Oct 2000, Gary E. Miller wrote:
>
> > Yo Mike!
> >
> > On Wed, 18 Oct 2000, Mike Galbraith wrote:
> >
> > > > Help! See below for my kernel oops. I have not been able to use any
> > > > kernel after 2.4.0-test5 due to this problem. It happens shortly
> > > > after booting the kernel and is very repeatable.
> >
> > > Are you sure that you used the right System.map?
> > Yes, I just rechecked the date and time of all the files. I will
> > re-run the whole test in the morning just to be sure.
> >
> > > > Trace; c01df362 <scsi_dispatch_cmd+1c6/26c>
> > > ^^^
> > > Here, scsi_dispatch_cmd() isn't that large.. it's only 0x168 in size.
> > Mine is 0x26c, maybe you have a different compiler or different config?
>
> Ok, I don't _see_ what could make such a big difference, but something
> obviously does.

(Decides to take another peek. Yup, scsi logging adds quite a bit)

Looks like deadlock at scsi.c:696 to me. ide_end_request() has the
io_request_lock on cpu0 and we try to grab it again with the same cpu.

What is unclear to me (SMP.. technology, sufficiently advanced.. magic)
is how in the heck the scsi interrupt happened on cpu0. It _looks_ to
me as though md_spin_unlock_irq() enabled interrupts at a very bad time.

>>EIP; c0272362 <stext_lock+4ba2/a820> <=====
Trace; c01df362 <scsi_dispatch_cmd+1c6/26c> scsi.c:696 deadlock cpu0
Trace; c010cab1 <handle_IRQ_event+59/84>
Trace; c010cc98 <do_IRQ+a8/fc> Uhoh!
Trace; c010b370 <ret_from_intr+0/20>
Trace; c02215d3 <raid1_end_bh_io+13b/148> md_spin_unlock_irq()!!
Trace; c022167a <raid1_end_request+9a/a4>
Trace; c01927c9 <end_that_request_first+65/c4> ll_rw_blk.c:1000
Trace; c01c99a8 <ide_end_request+34/88> ide.c:516 (cpu0 has lock,
Trace; c01cdadb <write_intr+ab/128> (interrupts are disabled)
Trace; c01cb27e <ide_intr+12a/194>
Trace; c01cda30 <write_intr+0/128>
Trace; c010cab1 <handle_IRQ_event+59/84>
Trace; c010cc98 <do_IRQ+a8/fc>
Trace; c010b370 <ret_from_intr+0/20>
Code; c0272362 <stext_lock+4ba2/a820>

If this were happening on my system, I'd boldly change raid1_free_bh()
like such..

--- drivers/md/raid1.c.org Wed Oct 18 15:30:07 2000
+++ drivers/md/raid1.c Wed Oct 18 15:33:08 2000
@@ -91,7 +91,8 @@

static inline void raid1_free_bh(raid1_conf_t *conf, struct buffer_head *bh)
{
- md_spin_lock_irq(&conf->device_lock);
+ unsigned long flags;
+ md_spin_lock_irqsave(&conf->device_lock, flags);
while (bh) {
struct buffer_head *t = bh;
bh=bh->b_next;
@@ -103,7 +104,7 @@
conf->freebh_cnt++;
}
}
- md_spin_unlock_irq(&conf->device_lock);
+ md_spin_unlock_irqrestore(&conf->device_lock, flags);
wake_up(&conf->wait_buffer);
}

..and see if the problem went away.
Now, if I'm off base, someone please clean my clock so I'll understand
better next time I foolishly attempt to figure out an SMP deadlock ;-)

-Mike

-
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/

\
 
 \ /
  Last update: 2005-03-22 12:41    [W:0.044 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site