Gabriel Paubert wrote:
>
> On Thu, 14 May 1998, Edgar Toernig wrote:
>
> > MOLNAR Ingo wrote:
> > > 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:
(Doc-ID 290566-001 :-)
>
> 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.
^^^^^^
That's exactly what I want.
> 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 the last sentence. An active level results in an interrupt. If
in INT-line is active while masked and then unmasked, it will generate an
immediate interrupt. What else should the IO-APIC do? Wait the pin
to go to an inactive state and then again to an active one? That would
be edge triggered. No! The active level generates the IRQ provided
there is no unacked IRQ for the same line.
That's the reason why they have the Remote-IRR bit. It's an additional
mask. As long as it is 1 no further IRQs are deliverd. If the local
APIC send the EOI, it is cleared and another IRQ may be send.
You don't need this with edge-triggered interrupts because every detected
edge will generate an IRQ wether the slave APIC is ready or not. But
for level-triggered ints you need something like this else you would
send IRQ storms as long as the i/o-device has its int-line active.
> 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 ;)
:-) But I'm still not convinced that we loose level-triggered interrupts.
At least with the NE2k prob, the IRQ has reached the IO-APIC and was send
to the local APIC...
Ok, bad designed i/o-devices may do all kind harm. Think of a chip with
level triggered interrupts, which only set its int-register on arrival of
a new packet instead of setting it as long as a packet is ready. It would
be very hairy (if not impossible) to get something like this to work
reliable...
Ciao, ET.
PS: I'll make a test. With MOLNAR's patch the mask-bit is unused. So
I will toggled it every say 160ms for the NE2k. Let's see what happens...
PPS: Did it. Ping time between 0.6ms and 160ms but no packet lost.
Prove enough? :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu