Alan et al,
I've got a hard lockup on 2.4.16 when I insmod sbp2 for my external
FW disk drive (ADS enclosure kit). I'm not using the official RH 2.4.9-13
RPM because the SRPM didn't build an SMP kernel and I had been
having no problems with 2.4.16ctx-4 (that's with Jacques Gelinas'
vserver patch). Anyhow, when I built a new kernel to support my
new Via Firewire Card (SB-FW6306-3l), I built it with the nesc.
ieee1394 support in modules. However:
cd /lib/modules/2.4.16-ctx4/kernel/drivers/ieee1394
insmod ieee1394
insmod ohci1394
insmod raw1394
insmod sbp2 (HARD LOCKUP)
I can rebuild again with SysRq patch if you think that'll help. I
can also forward my kernel build ".config" file and my sysreport
to Alan if he likes. (I've already sent a ticket to [email protected].
about the SMP kernel problems.)
TIA
[email protected].
Timothy Covell wrote:
>
> lockup
> ...
> sbp2
> ...
> SMP
> ...
--- linux-2.4.17-pre8/drivers/ieee1394/sbp2.c Mon Dec 10 13:46:20 2001
+++ linux-akpm/drivers/ieee1394/sbp2.c Wed Dec 12 20:50:16 2001
@@ -2773,7 +2773,9 @@ static void sbp2scsi_complete_command(st
/*
* Tell scsi stack that we're done with this command
*/
+ spin_lock_irq(&io_request_lock);
done (SCpnt);
+ spin_unlock_irq(&io_request_lock);
return;
}
-
Hrm...
Does this apply to usb-storage also? Under what conditions do you need to
hold the io_request_lock when calling the done function?
usb-storage calls it from task context, not from IRQ context.... if that
makes any difference.
Matt
On Fri, Dec 28, 2001 at 07:51:23PM -0800, Andrew Morton wrote:
> Timothy Covell wrote:
> >
> > lockup
> > ...
> > sbp2
> > ...
> > SMP
> > ...
>
> --- linux-2.4.17-pre8/drivers/ieee1394/sbp2.c Mon Dec 10 13:46:20 2001
> +++ linux-akpm/drivers/ieee1394/sbp2.c Wed Dec 12 20:50:16 2001
> @@ -2773,7 +2773,9 @@ static void sbp2scsi_complete_command(st
> /*
> * Tell scsi stack that we're done with this command
> */
> + spin_lock_irq(&io_request_lock);
> done (SCpnt);
> + spin_unlock_irq(&io_request_lock);
>
> return;
> }
>
> -
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver
Da. Am thinkink of carbonated borscht for lonk nights of coding.
-- Pitr
User Friendly, 7/24/1998
Matthew Dharm wrote:
>
> Hrm...
>
> Does this apply to usb-storage also? Under what conditions do you need to
> hold the io_request_lock when calling the done function?
>
That's scsi_old_done(). I don't think scsi_done() cares whether
io_request_lock is held or not.
And io_request_lock *must* be held by the caller of scsi_old_done() - it
assumes this. I think we'd have heard by now if usb was getting this
wrong. Looks like it's using scsi_done(), yes?
-
It should be using scsi_done()... it actually seems to use whatever was
given as a done function at the queuecommand point, which is, I think,
scsi_done().
Matt
On Fri, Dec 28, 2001 at 08:59:17PM -0800, Andrew Morton wrote:
> Matthew Dharm wrote:
> >
> > Hrm...
> >
> > Does this apply to usb-storage also? Under what conditions do you need to
> > hold the io_request_lock when calling the done function?
> >
>
> That's scsi_old_done(). I don't think scsi_done() cares whether
> io_request_lock is held or not.
>
> And io_request_lock *must* be held by the caller of scsi_old_done() - it
> assumes this. I think we'd have heard by now if usb was getting this
> wrong. Looks like it's using scsi_done(), yes?
>
> -
--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver
Sir, for the hundreth time, we do NOT carry 600-round boxes of belt-fed
suction darts!
-- Salesperson to Greg
User Friendly, 12/30/1997
On Friday 28 December 2001 21:51, you wrote:
> Timothy Covell wrote:
> > lockup
> > ...
> > sbp2
> > ...
> > SMP
> > ...
>
> --- linux-2.4.17-pre8/drivers/ieee1394/sbp2.c Mon Dec 10 13:46:20 2001
> +++ linux-akpm/drivers/ieee1394/sbp2.c Wed Dec 12 20:50:16 2001
> @@ -2773,7 +2773,9 @@ static void sbp2scsi_complete_command(st
> /*
> * Tell scsi stack that we're done with this command
> */
> + spin_lock_irq(&io_request_lock);
> done (SCpnt);
> + spin_unlock_irq(&io_request_lock);
>
> return;
> }
>
>
That did the trick. I'm writing this on 2.4.16-ctx4 with this patch on SMP.
It's amazing what a little spin lock will do. Thanks!
(Even if I had realized that this was fixed on 2.4.17, I had other issues
with 2.4.17 which prevented me from wanting to run it.)
[email protected].