[8267] in linux-scsi channel archive
Re: queueing commands and IRQs?
daemon@ATHENA.MIT.EDU (Eric Youngdale)
Mon Feb 28 22:51:57 2000
Message-ID: <00f001bf825c$7a24afd0$0f17a8c0@eric.home>
From: "Eric Youngdale" <eric@andante.org>
To: "Matthew Dharm" <mdharm-scsi@one-eyed-alien.net>,
"Kurt Garloff" <garloff@suse.de>
Cc: "The Linux SCSI list" <linux-scsi@vger.rutgers.edu>
Date: Mon, 28 Feb 2000 21:27:08 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
> > This is true for the old exception handling. I think it was one of the
> > objectives to remove this behaviour in the new EH code, but I'm not sure
> > it's always accomplished. Eric Youngdale should be able to comment on
that.
> >
> > Anyway, I think you need to use the irq safe spinlock anyway, cause
> > otherwise you risk:
> >
> > queue_command(): spinlock
> > IRQ -> irq handler: spinlock_irqsave() will deadlock!!
>
> But I don't have an IRQ handler that will try to obtain the lock. The
> only thing I'm worried about is:
>
> IRQ -> irq handler -> queuecommand()
>
> If that can't happen, then I'm free and clear to use the non IRQ-safe
> spinlocks.
When you are using the new error handling code, the post-processing of
commands is done from a bottom-half handler. Thus your interrupt handler
will have returned by the time that a queuecommand is called again. Keep
in mind that on an SMP machine you could have an interrupt being handled on
one processor and a new command being queued on a second processor - this is
why we tend to always use the IRQ safe spinlocks throughout SCSI.
Also, the bottom half handlers are run while the processor is
interrupted. By this I mean that some other task was still pre-empted when
the handler runs. The thing you gain is that you can guarantee that your
low-level handler has returned before the queuecommand function is called
again.
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
