Eric W. Biederman schrieb:
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?

That's exactly the reason why disabling them is a bad idea, you end up
having devices fixed to IO-APIC pins that boot interrupts are routed to.

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.
> 
> If that is what your patches implement I disagree with that approach
> for the mainstream kernel.

You're right, that behavior is more appropriate for RT, where we see
these boot interrupts because of the way interrupts are handled there.
We're rewriting the patches to use a parameter like pci=ioapicreroute to
trigger this only if the parameter is specified (for the mainstream
kernel).

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

  Stefan
-- 
Stefan Assmann          | SUSE LINUX Products GmbH
Software Engineer       | Maxfeldstr. 5, D-90409 Nuernberg
Mail : sassmann@suse.de | GF: Markus Rex, HRB 16746 (AG Nuernberg)
--
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/