spurious smp_spurious_interrupt()?

[Jonathan Lundell]

What's the source of the "never happen" comment in 
arch/i386/kernel/apic.c (repeated in the printk)? It plainly *does* 
happen (as Google and my own experience attest--look for 
call_spurious_interrupt, though), and there's nothing in Intel's 
documentation to suggest that it shouldn't, or that it's anything but 
a routine (though presumably rare) occurrence.

(Note also that the documentation reference is no longer correct. In 
the 2001 edition it was 7.6.13.5; in the latest edition the APIC gets 
its own chapter.)

>8.9. SPURIOUS INTERRUPT
>A special situation may occur when a processor raises its task 
>priority to be greater than or equal to the level of the interrupt 
>for which the processor INTR signal is currently being asserted. If 
>at the time the INTA cycle is issued, the interrupt that was to be 
>dispensed has become masked (programmed by software), the local APIC 
>will deliver a spurious-interrupt vector. Dispensing the 
>spurious-interrupt vector does not affect the ISR, so the handler 
>for this vector should return without an EOI.

>/*
>  * This interrupt should _never_ happen with our APIC/SMP architecture
>  */
>asmlinkage void smp_spurious_interrupt(void)
>{
>         unsigned long v;
>
>         /*
>          * Check if this really is a spurious interrupt and ACK it
>          * if it is a vectored one.  Just in case...
>          * Spurious interrupts should not be ACKed.
>          */ 
>         v = apic_read(APIC_ISR + ((SPURIOUS_APIC_VECTOR & ~0x1f) >> 1));
>         if (v & (1 << (SPURIOUS_APIC_VECTOR & 0x1f)))
>                 ack_APIC_irq();
>
>         /* see sw-dev-man vol 3, chapter 7.4.13.5 */
>         printk(KERN_INFO "spurious APIC interrupt on CPU#%d, should 
>never happen
>.\n",
>                         smp_processor_id());
>}

-- 
/Jonathan Lundell.