lkml.org 
[lkml]   [2008]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/7] Boot IRQ quirks and rerouting
    On 04-Jun-08, Eric W. Biederman wrote:
    > Stefan Assmann <sassmann@suse.de> writes:
    >
    > > On the chips (ICHx, ...) we saw, the interrupt lines on the PIC also go
    > > to the first IO-APIC. So the boot interrupts go to both the PIC and the
    > > first IO-APIC.
    > >
    > > When running in APIC mode all PIC IRQs are disabled, except for the
    > > timer maybe. Boot interrupts still arrive on the first IO-APIC and end
    > > up as being counted as spurious interrupts.
    >
    > So the boot interrupt comes in on one of the legacy irq vectors on
    > the first ioapic, but it is a native ioapic irq.
    >
    > What is the reason why you don't simply disable the ioapic vector of
    > the boot interrupt? Do some devices not use anything else?

    Yes, other devices do use the same ioapic irq. Depending on the chipset
    and mainboard wiring, these other devices can or cannot be moved to a
    different IRQ. Also, this changes with chipset generations and there are
    several registers to consider for every chipset to re-route these
    devices.

    This solution would need to be worked on intesively, it will not work
    often enough and also maintenance would cost a lot of time.

    On the other hand, we see the reroute patch as a legacy support
    workaround. Newer chipsets can usually disable the boot interrupt. But
    devices like the 6700PXH are still around a lot.

    None of the newer chipsets we looked at needs a workaround like
    re-routing.

    > > The lines where the boot interrupts show up are usually hard wired to
    > > the first IO-APIC. It might be possible to move devices that share these
    > > lines to other interrupts but in many cases, especially on older ICHs,
    > > this is not possible.
    >
    > Not what I was suggesting.
    >
    > As I read the above. It says:
    > When you can not disable the boot interrupt you don't attempt to use
    > the non-boot interrupts and use the boot interrupt for everything.

    Right.

    > If that is what your patches implement I disagree with that approach
    > for the mainstream kernel.

    Amongst all the approaches we discussed before creating the patch, this
    was the only working solution.

    What would be your suggestion to handle boot interrupts that cannot be
    disabled?

    > > The wiring of the boot interrupts follows a fixed pattern on most
    > > bridges and generates a PCI IRQ. This ends up on the ICH or equivalent,
    > > where it either is hard-wired to IRQ 16 to 24, or can be routed to
    > > some IRQ through a programmable mapping. An example for the mappings
    > > on intel chips is in another mail in this thread.
    >
    > I will have to look. I am familiar with the concept but I have

    Yes, please. :)

    > not looked at any of these in detail for a while.
    >
    > >> For the mainstream kernel I expect we can even teach the drivers
    > >> not to call disable_irq. As a function of last resort to deal
    > >> with screaming irqs, disable_irq seems reasonable. Using disable_irq
    > >> on a regular basis appears to be asking for a trouble (as you have
    > >> found).
    > >
    > > We see these boot interrupts mainly in the RT kernels, which handle
    > > interrupts in threads. To do this, they mask the IRQ until it has been
    > > handled. The masking sets up the conditions on the chip so that boot
    > > interrupts are generated.
    >
    > Yes. My point being that because we don't do that in the mainstream
    > kernels we have more robust alternatives in the mainstream kernel.

    The mainline kernel uses masking to disable IRQ lines. The IRQ should
    then not appear somewhere else and cause spurious interrupts. This is
    the reason why we believe the reroute patch is also beneficial to the
    mainline kernel.

    That being said, I also would be glad if we had an elegant solution.

    > > Some chips (6700PXH, ...) are not PCIe 2.x (IIR the version correctly)
    > > compatible, and they do not support switching off INTx generation.
    > > We tried this anyway for the 6700PXH and it did not work.
    >
    > So much for that idea then.
    >
    > Eric

    Thanks a lot, :)

    --
    Olaf Dabrunz (od/odabrunz), SUSE Linux Products GmbH, Nürnberg

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2008-06-04 13:39    [W:4.323 / U:0.224 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site