> > the problem with this is that we loose IRQs which arrive while they are
> > masked in the IO-APIC. So if a driver (say eth0) handles one specific
> > frame, and a status flag says there are no more frames, and the driver
> > clears the IRQ, and is on it's way back to the higher-level IRQ code,
> > _and_ we get another frame in this window, then we will loose this IRQ.
>
> 1. Why should we loose it? It's level triggered! As soon as the APIC
> is unmasked/reenabled the IRQ comes through.
>
> 2. We are/I'm *not* loosing interrupts. The interrupts stick in the
> IO-APIC (see delivery-status and remote-irr flags). They wait to
> be acked. Loosing interrupts would slow down the 8390-driver
> (it resets the card and discards packet when it detects a lost int)
> but wouldn't make him dead.
>
> > Enabling a pin for a raised level-triggered IRQ does _not_ generate an
> > IRQ as far as i've checked. Yes it sucks.
>
> Unmasking an already active level-triggered pin does of course generate
> an IRQ. Your statement is right for edge-triggered interrupts; the
> IO-APIC wants to /see/ the edge while unmasked but for level-
> triggered interrupts the level alone is enough (else they would be
> edge-triggered ints, too, right? :-)
No! From my IO-APIC doc in the I/O redirection table register description:
Interrupt Mask-R/W interrupts signaled on a masked interrupt pin are
ignored (i.e., not delivered or held pending). LEVEL-ASSERTS OR NEGATES
OCCURRING ON A MASKED LEVEL-SENSITIVE PIN ARE ALSO IGNORED AND
HAVE NO EFFECT. Changing the mask bit from unmasked to masked after the
interrupt is accepted by a local APIC has no effect on that interrupt.
This behavior is identical to the case where the device withdraws the
interrupt before that interrupt is posted to the processor. It is
software's responsibility to handle the case where the mask bit is set
after the interrupt message has been accepted by a local APIC unit but
before the interrupt is dispensed to the processor. When this bit is 0,
the interrupt is not masked. An edge or level on an interrupt pin that is
not masked results in the delivery of the interrupt to the destination.
Note that I never thought that such a thing would be possible after
working with buses like VME for years (which exclusively use simple
level-triggered interrupts schemes) and cannot lose them. But I have to
praise Intel since they have shown me that I was wrong by coming up with
this new concept: losable level-triggered interrupts ;) It truly takes
the R&D resources of a multibillion dollar company to reach this level of
cutting-edge innovation ;)
Gabriel.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu