Subject: kern/11958: IEEE 1394 code mixes interrupt levels
To: None <email@example.com>
From: None <firstname.lastname@example.org>
Date: 01/14/2001 13:44:16
>Synopsis: IEEE 1394 code mixes interrupt levels
>Arrival-Date: Sun Jan 14 13:44:00 PST 2001
>Originator: Jason R. Thorpe
>Release: Jan 14, 2000 NetBSD-current
Zembu Labs, Inc.
System: NetBSD dr-evil 1.5Q NetBSD 1.5Q (DR-EVIL) #54: Thu Jan 11 13:06:44 PST 2001 thorpej@dr-evil:/u1/netbsd/src/sys/arch/i386/compile/DR-EVIL i386
[ Note, this PR is similar to kern/11957, filed against the
USB code. ]
1394 completion processing happens at controller interrupt
As a result of this, the network support in fwohci uses
splimp() to block both network and 1394 controller interrupts.
Besides generally being bad (blocks more interrupts than you
would otherwise need), it is a roadblock for some pending SMP
work (it is critical that this problem be fixed so that MP-safe
interrupt handlers can be integrated).
There are a couple of ways this could be fixed. The easiest,
it seems, would be to have the controller (fwohci) defer all
of the real interrupt processing to a software interrupt (either
using the softintr_schedule() API, if present, or a callout with
a tick count of 1; the lack of softintr_schedule() everywhere is
a bug orthogonal to this one).
With this approach, the controller drivers could then simply
be considered "bio" devices, and controller interrupts could
be registered with IPL_BIO and blocked with splbio(), and
a spl1394() (you'll probably want to pick a better name)
could be defined to splsoftclock().
Then the network support in fwohci (and eventually all other
1394 device drivers) can go to splnet() (or whichever level
is appropriate) at the appropriate times.