On 04-Jun-08, Eric W. Biederman wrote:
quoted text
> 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.

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

quoted text
> 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?

quoted text
> > 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. :)

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

quoted text
> > 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

--
unsubscribe notice
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/