Subject: Re: Bug in x86 ioapic interrupt code for devices with shared interrupts?
To: Tom Spindler <dogcow@babymeat.com>
From: None <jonathan@dsg.stanford.edu>
List: port-i386
Date: 03/03/2006 11:48:33
In message <20060303190721.GA13524@babymeat.com>Tom Spindler writes
>> I am aware that it is *also* a bug in bge(4) -- it only requires the
>> deletion of #if 0 / #endif to fix -- 

As I've commented earlier, my experience is that Thor's statement is
incorrect: enabling the code in bge_intr() inside #ifdef notdef/#endif
causes even more severe problems, on the systems where I've tried it.

Thor, Jason: Suppose, for the sake of argument, one is writing a
NetBSD driver for hardware where it's not always possible to tell
whether the device generated an interrupt on a shared IRQ, or not.

What should the interrupt routine return in that case?



>> interrupts are being routed to the wrong devices.  There is plenty
>> of other interrupt-related misbehavior on amd64 machines and getting
>> to the bottom of this might help.
>
>It wouldn't be surprising if this were also the root cause of the
>misbehavior of (athlon-based) nforce4 systems' built-in devices.

Huh? I think it'd be *extremely* surprising, since nforce4 chips have
no built-in bge device, and the various problems with NetBSD on
amd64+nforce4 systems occur regardless of whether or not any add-in
bge devices are present.

So I'm reading and re-reading this, trying to guess what you meant.
Is it possible you think that our drivers for PCI functions built into
nforce4 chips have a similar #ifdef?