Subject: Re: Bug in x86 ioapic interrupt code for devices with shared interrupts?
To: None <jonathan@dsg.stanford.edu>
From: Thor Lancelot Simon <tls@rek.tjls.com>
List: port-i386
Date: 03/03/2006 14:55:34
On Fri, Mar 03, 2006 at 11:48:33AM -0800, jonathan@dsg.stanford.edu wrote:
> 
> In message <20060303190721.GA13524@babymeat.com>Tom Spindler writes
> >
> >It wouldn't be surprising if this were also the root cause of the
> >misbehavior of (athlon-based) nforce4 systems' built-in devices.
> 
> 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?

No.  He's noting -- as am I -- that the basic problem in the configuration
I described seems to be *that the bge driver gets an interrupt at all*.
What happens when it acks an interrupt that didn't actually come from its
hardware is just an ancillary issue that makes the underlying problem more
obvious.

The amr and the bge, on the system I described, have been assigned the
same *IRQ* -- but they're on *different* ioapics.  If the bge's interrupt
routine gets called when the amr hardware generates an interrupt, or
vice versa, something's being routed wrong, at least if I understand
what the code is meant to do.  Tom is suggesting that such an interrupt
routing issue when ioapics are in use could be responsible for the
problems observed with nforce4 boards.

-- 
  Thor Lancelot Simon	                                     tls@rek.tjls.com

  "We cannot usually in social life pursue a single value or a single moral
   aim, untroubled by the need to compromise with others."      - H.L.A. Hart