Re: Potential source of interrupt aliasing

From: Matthew Dillon <dillon_at_apollo.backplane.com>
Date: Sun, 10 Apr 2005 17:12:12 -0700 (PDT)
    A couple of things don't click here.

    First, unless this 'boot interrupt' IRQ is pointing to an APIC vector 
    that is initialized to point at the softclock there is no way the
    softclock ithread could be involved.  I'm not saying that it isn't
    running away, just that the boot interrupt business is probably not
    the cause.  This boot interrupt thingy kinda sounds like a red herring.

    Secondly, you HAVE to mask the APIC vector in the interrupt service
    routine if the service routine is going to schedule an ithread.  There's
    no choice... it HAS to be done because the ISR isn't capable of clearing
    the originating interrupt from the device... the interrupt thread has to
    do that.

    *BUT* it *IS* possible that the wrong APIC vector is being masked (and
    not because of an interrupt alias, but because the actual hard interrupt
    is misrouted).  I've seen this occur numerous times.  What happens is
    that a device generates an mis-routed interrupt which causes the
    interrupt handler for an UNRELATED device to run.  It runs to completion
    but since the device it thought interrupted was not the device that
    actually interrupted, the interrupt on the actual originating device 
    never gets cleared so the moment the ithread completes and unmasks that
    APIC vector, the APIC issues another interrupt.  The result is that the
    ithread is constantly running.

    Misrouted interrupts are a serious problem.  They seem to be caused by
    the BIOS or ACPI getting confused about how bridges are wired... when
    multiple devices route an interrupt through the same pin on a bridge
    and one is routed, the BIOS or ACPI gets seriously confused about
    the second device and may believe that the second device can be routed
    to a different IRQ when, in fact, it can't.  You wind up with one of
    the two devices on the wrong IRQ.  This problem is exasperated when 
    the BIOS routes some of the devices for use by the BIOS (such as for
    PXE booting), or to handle a USB keyboard, or something of that sort.

						-Matt
Received on Sun Apr 10 2005 - 22:12:12 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:31 UTC