Fwd: Hard Lockup on 2.4.16 with Via ieee1394 (sbp2 mode)

Fwd: Hard Lockup on 2.4.16 with Via ieee1394 (sbp2 mode)

[Timothy Covell]

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 support@redhat.com.
about the SMP kernel problems.)

TIA

timothy.covell@ashavan.org.

Re: Fwd: Hard Lockup on 2.4.16 with Via ieee1394 (sbp2 mode)

[Andrew Morton]

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;
 }

-

Re: Fwd: Hard Lockup on 2.4.16 with Via ieee1394 (sbp2 mode)

[Matthew Dharm]

[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

Da.  Am thinkink of carbonated borscht for lonk nights of coding.
					-- Pitr
User Friendly, 7/24/1998

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Fwd: Hard Lockup on 2.4.16 with Via ieee1394 (sbp2 mode)

[Andrew Morton]

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?

-

Re: Fwd: Hard Lockup on 2.4.16 with Via ieee1394 (sbp2 mode)

[Matthew Dharm]

[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]

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: mdharm-usb@one-eyed-alien.net 
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

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Fwd: Hard Lockup on 2.4.16 with Via ieee1394 (sbp2 mode)

[Timothy Covell]

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.)

timothy.covell@ashavan.org.