Re: [PATCH 0/7] Boot IRQ quirks and rerouting

[Olaf Dabrunz <od@suse.de>]

Hello Thomas, :)

On 03-Jun-08, Thomas Gleixner wrote:
> Olaf,
> 
> On Mon, 2 Jun 2008, Olaf Dabrunz wrote:
> > These patches are against linux-2.6-tip, auto-x86-next.
> > 
> > When IRQ lines on secondary or higher IO-APICs are masked (as done by
> > RT and others), many chipsets redirect IRQs on this line to the PIC, and
> > thereby regularly to the first IO-APIC in the system. This causes
> > spurious interrupts and can lead to disabled IRQ lines.
> > 
> > Disabling this "boot interrupt" (as it is mostly used to supply all
> > IRQs to the legacy PIC during boot) is chipset-specific, and not
> > possible for all chips. This patchset disables the boot interrupt on
> > chipsets where this is possible and where we know how to do it.
> > 
> > When disabling the boot interrupt is not possible, the patches tell the
> > IRQ code to always use the redirected interrupt line (on the first
> > IO-APIC) instead of the "original" line on the secondary (tertiary ...)
> > IO-APIC. The original line remains masked, and IRQs always appear on
> > the boot interrupt line on the first IO-APIC instead.
> 
> Thanks for doing the research on this problem. 
> 
> We probably don't want to enable this unconditionally right away, so
> we should have a command line option which enables these quirks.

Is this part of the process (sth like: keep it disabled until we trust
it)?

Otherwise I would suggest to enable the "disable-quirks" by default
(when we use the APICs), and to disable the reroute stuff by default
until people trust it.

The "disable-quirks" are what some chipset documentation recommends to
do in the ACPI "_PIC" method anyway, when APIC mode is selected by the
operating system. I have seen a few BIOSes that do exactly the same in
the "_PIC" method. They are straightforward and simple. I believe they
are safe in APIC mode (and off in PIC mode) and we should expose them to
testing.

The reroute patch is a bit of a hack for the chips where boot interrupts
cannot be switched off. It is a simple approach, and I can think up
(so far theoretical) scenarios where it breaks.

In defense of the reroute patch:

    - we have not seen it break during our testing on more than 10 intel
      machines (with and without chips on which it is used) and

    - so far the rerouting was only necessary for some intel bridges,
      and I checked that

        1) all these bridges use the same routing for boot interrupts to
           PCI IRQs, as in the i6700PXH datasheet, section 2.15.2:

                Pin          INT

                0,4,8,12  -> INTA
                1,5,9,13  -> INTB
                2,6,10,14 -> INTC
                3,7,11,15 -> INTD

           (also note that this routing pattern is required by the PCI
           specs for _cards_ that add PCI bridges, as the BIOS cannot
           otherwise know the routing)

        2) all intel ICHxs use the same routing for external PCI IRQs to
           the ICHx's IO-APIC, as in the ICH5 datasheet, section 5.9.2:

                Direct
                from Pin     IRQ #

                PIRQA#    -> 16
                PIRQB#    -> 17
                PIRQC#    -> 18
                PIRQD#    -> 19
                PIRQE#    -> 20
                PIRQF#    -> 21
                PIRQG#    -> 22
                PIRQH#    -> 23

      and as the ICH provides a PIC, it needs to be the first interrupt
      controller in the system, unless another chip also provides a PIC.

To break the reroute patch, someone would need to connect the PCI IRQs
from an intel PCI bridge that cannot disable boot interrupts
(6700PX[VH], 8033[23] or 6300ESB) to something other than an intel ICHx.
I have never seen such a board and I doubt there will be many such
boards.

> Also is there any interaction with MSI ?

The docs for the 6700PX[VH], and IIRC also for the 8033[23] or 6300ESB
say that boot irqs are generated when the original ones are masked. So
this is independent of MSI.

We have not many boards where MSI is enabled (as there are quirks for
many chips that switch MSI off). But our testing showed no problems on
MSI-enabled machines.

> Thanks,
> 	tglx

Thanks, :)

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