Subject: Re: Bug in x86 ioapic interrupt code for devices with shared interrupts?
To: Tom Spindler <email@example.com>
From: None <firstname.lastname@example.org>
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?