Re: [Xenomai-help] keyboard interrupt

[Harco Kuppens <h.kuppens@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 6037 bytes --]


everything is getting clearer know thanks :)
but still a got some things not really clear to may,
hope you still have time to answer them.


Jan Kiszka wrote:
> Yes. For correct handling of shared IRQs, _all_ associate IRQ handlers
> must have been executed before the EOI can be sent. The reason is this:
>
> For level-triggered IRQs, all hardware devices that may have raised the
> IRQ line must be checked and told to lower it again before sending EOI.
> Otherwise the IRQ will immediately be triggered again and you end up in
> an endless loop, bricking your box.
>   
ok, a raised line does not the information how many devices could have 
raised them, so you have to handle them all to prevent missing one.
only after handling them all (they all are lowered) you can send  
'end-of-IRQ' signal

thus when after handling one device all other devices have to be 
rechecked because  in the meantime they could have raised the line
> For edge-triggered IRQs, there problem is different. Here the shared IRQ
> handling algorithm is to consult all handler in a loop until they all
> reported "not for me" in a row. If you fail to do this, you risk loosing
> IRQs. 
> Consider IRQ source A and B. Now an IRQ is raised by B. First, the
> handler for A will be called. It return "not for me". Now it happens
> that A also raised the IRQ right at this time. If you now simply log the
> IRQ for later handling by B and send the EOI, you take away the chance
> for handle A to react on the IRQ. At best you create latency, at worst A
> will never send an IRQ again...
>   
so you should after handling B again have to call all handlers to see if 
they report all "not for me" ?
so you would call handler A twice, right?


Thus when finally when handled all device you send the 'end-of-IRQ' signal.

After reading the explanation above I suppose that when handling an IRQ 
X, there are no new entries for that IRQ X stored in  the PIC controller.
So the next interrupt after the 'end-of-IRQ' signal will be another 
interrupt than the one we just dealed.

at section  8.8.4 off the Intel APIC documentation  /IA-32 Intel 
Architecture Software Developer's Manual, Volume 3A: System Programming 
Guide, Part 1 
<http://developer.intel.com/design/processor/manuals/253668.pdf>/ I read 
a very clear piece of explaining text :

    The local APIC queues the fixed interrupts that it accepts in one of
    two interrupt pending registers: the interrupt request register
    (IRR) or in-service register (ISR). These two 256-bit read-only
    registers are shown in Figure 8-20. The 256 bits in these registers
    represent the 256 possible vectors; vectors 0 through 15 are
    reserved by the APIC (see also: Section 8.5.2, "Valid Interrupt
    Vectors").

    The IRR contains the active interrupt requests that have been
    accepted, but not yet dispatched to the processor for servicing.
    When the local APIC accepts an interrupt, it sets the bit in the IRR
    that corresponds the vector of the accepted interrupt. When the
    processor core is ready to handle the next interrupt, the local APIC
    clears the highest priority IRR bit that is set and sets the
    corresponding ISR bit. The vector for the highest priority bit set
    in the ISR is then dispatched to the processor core for servicing.

    While the processor is servicing the highest priority interrupt, the
    local APIC can send additional fixed interrupts by setting bits in
    the IRR. When the interrupt service routine issues a write to the
    EOI register (see Section 8.8.5, "Signaling Interrupt Servicing
    Completion"), the local APIC responds by clearing the highest
    priority ISR bit that is set. It then repeats the process of
    clearing the highest priority bit in the IRR and setting the
    corresponding bit in the ISR. The processor core then begins
    executing the service routing for the highest priority bit set in
    the ISR.

    If more than one interrupt is generated with the same vector number,
    the local APIC can set the bit for the vector both in the IRR and
    the ISR. This means that for the Pentium 4 and Intel Xeon
    processors, the IRR and ISR can queue two interrupts for each
    interrupt vector: one in the IRR and one in the ISR. Any additional
    interrupts issued for the same interrupt vector are collapsed into
    the single bit in the IRR.

    For the P6 family and Pentium processors, the IRR and ISR registers
    can queue no more than two interrupts per priority level, and will
    reject other interrupts that are received within the same priority
    level.

    If the local APIC receives an interrupt with a priority higher than
    that of the interrupt currently in serviced, and interrupts are
    enabled in the processor core, the local APIC dispatches the higher
    priority interrupt to the processor immediately (without waiting for
    a write to the EOI register). The currently executing interrupt
    handler is then interrupted so the higher-priority interrupt can be
    handled. When the handling of the higher-priority interrupt has been
    completed, the servicing of the interrupted interrupt is resumed.



So another interrupt can be queued in the APIC  in the IRR register though.
But we just handled all devices for that IRQ, so I would say it could be 
skipped. Or not?


I'm also I little bit confused about the term "acknowledge", I couldn't 
find that word in the intel documentation.
In your previous mail you said that linux did the "acking".
In a book I found it means unblocking the PIC, but I would suppose not 
for the IRQ handled, but for all other IRQ's.
Because I understand now that no other IRQs of the same type cann't be 
handled until the 'end-of-IRQ' signal.

Thus what does 'acknowledege' exactly mean?



For everyone interested I also found a nice description about  Level- 
and Edge triggered interrupts  at wikipedia confirming your story at :
  http://en.wikipedia.org/wiki/Interrupt#Level-triggered


Thanks for all help.

cheers
Harco




[-- Attachment #2: Type: text/html, Size: 6894 bytes --]