[3413] in linux-scsi channel archive
Re: Race in AHA1542 detection
daemon@ATHENA.MIT.EDU (Eric Youngdale)
Fri Feb 27 01:14:34 1998
Date: Thu, 26 Feb 1998 23:34:01 -0500 (EST)
From: Eric Youngdale <eric@andante.jic.com>
To: Keith Owens <kaos@ocs.com.au>
cc: linux-scsi@vger.rutgers.edu
In-Reply-To: <19980223221211.20867.qmail@mail.ocs.com.au>
On Tue, 24 Feb 1998, Keith Owens wrote:
> On Mon, 23 Feb 1998 09:09:46 -0500 (EST),
> Eric Youngdale <eric@andante.jic.com> wrote:
> > Maybe I am reading the stuff below wrong, but it almost looks like
> >both processors are running the aha1542_detect() routine. If this is
> >true, it is almost certainly not correct.
>
> setup_mailboxes, aha1542_out, aha1542_detect are all running on cpu(0),
> pid(1). aha1542_detect calls request_irq on cpu(0) then proceeds to do
> the DMA work. With apic, after the irq has been assigned, cpu(1) takes
> an interrupt before aha1542_detect has ended.
>
>
> The normal fix to this problem is to use spinlocks instead of cli/sti,
> that is Linus's preferred direction. I can do the patch, but where to
> store the spinlock? Should it be global for all 1542's in a machine or
> local to each card? My feeling is local to each card which probably
> means adding a spinlock to the Scsi_Host structure. Before I do that
> and affect every other SCSI driver, it might be a good idea to agree on
> how to handle apic.
Before we make any changes, I want to understand what is going on.
Despite what you say the APIC stuff does, the scenario you are presenting
doesn't make any sense, and blindly adding a bunch of spinlocks isn't
likely to do any good. Besides, putting a spinlock in an interrupt
handler just seems wrong to me :-).
I understand moving away from cli()/sti() - especially in
performance critical code. The bootup detection of the card doesn't fall
into this category. Also I would expect that many if not all of the
low-level scsi drivers are going to have problems in this area, so
patching the 1542 driver seems like a band-aid to me.
Secondly why doesn't a global cli() block interrupts on all
processors when APIC is enabled? This seems like a bug to me - if not,
what exactly does cli() do in the context of APIC? When we are setting up
the card from the start, we need to make sure that we don't take an
interrupt at all until the configuration of the card is complete. For
example, we haven't finished registering the I/O space, and we haven't
registered the DMA channel. Taking an interrupt seems extremely dangerous
at this point.
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
