Subject: kern/11958: IEEE 1394 code mixes interrupt levels
To: None <>
From: None <>
List: netbsd-bugs
Date: 01/14/2001 13:44:16
>Number:         11958
>Category:       kern
>Synopsis:       IEEE 1394 code mixes interrupt levels
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>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
Architecture: i386
Machine: 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).

	Code inspection.

	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.