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

[Eric W. Biederman]

Stefan Assmann <sassmann@xxxxxxx> 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?

> 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.

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

> 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
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.

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