Bjorn Helgaas wrote: > On Tuesday 13 January 2009 08:57:17 am Olaf Dabrunz wrote: >> On 13-Jan-09, Stefan Assmann wrote: >>> Bjorn Helgaas wrote: >>>> (I added Eric, Maciej, and Jon because they participated in >>>> previous discussion here: http://lkml.org/lkml/2008/6/2/269) >>>> >>>> On Monday 12 January 2009 04:09:25 am Stefan Assmann wrote: >>>>> Len Brown wrote: >>>>>> Stefan, >>>>>> I had to exclude your changes to drivers/acpi/pci_irq.c from >>>>>> e1d3a90846b40ad3160bf4b648d36c6badad39ac >>>>>> in order to get some other changes to that file upstream in the >>>>>> 2.6.29 merge window. ... >>>>> Let me try to give you a short overview of what's happening there. >>>>> >>>>> If an IRQ arrives at line X of a non-primary IO-APIC and that line is >>>>> masked a new IRQ will be generated on the primary IO-APIC/PIC. This is >>>>> called a "Boot Interrupt" by Intel. It's purpose is, as the name >>>>> suggests, to ensure that the IRQ is handled at boot time (when the >>>>> non-primary) IO-APIC is still disabled. >>>>> >>>>> Condition to be met for "Boot Interrupts": >>>>> - line X on non-primary IO-APIC interrupt line is masked >>>>> - line X is asserted >>>> Thanks. Let me replay this to see whether I understand. Please >>>> correct any of my misapprehensions :-) >>>> >>>> Since your patch doesn't look at the IOxAPIC RDL register to see >>>> whether the pin is masked, you must be assuming that Linux is >>>> *always* using boot interrupts, and never unmasking the non-primary >>>> IOxAPIC entry. >>> Yes, for this special case that is correct. >> Right. The current reroute code assumes that all interrupts use masking. > > I'm not an expert in the "classic x86 ioapic behaviour" or in RT > interrupt handling. My main objections are that the patch as proposed > is a gross hack in the ACPI _PRT lookup path, and that it didn't touch > the non-ACPI lookup path, which should have the same problem. Now that I guess by non-ACPI path you refer to the MP_TABLE. So in case you boot with "acpi=off" the system falls back to the MP_TABLE information and this is not covered yet. > Eric pointed out this is just classic behavior, I also wonder why the > quirk doesn't list more devices. The reason why the list of quirks isn't larger is that there's no documentation available in public for some of the chipsets. For example for Nvidia and VIA chipsets. Note that there is only a problem if more than one IO-APIC exists in the system. Additional IO-APICs usually appear on PCI bridges. We have not encountered any systems yet that are Nvidia or VIA based with more than one IO-APIC. But your mileage may vary. > The effect of the patch sounds sort of similar to using "noapic" -- > you're basically ignoring the IOAPIC and using only the "boot interrupt" > or legacy PIC interrupt or whatever it is. Can you contrast it with > that? The main difference here is that "noapic" disables any IO-APIC in the system, whereas the patch leaves them intact. We won't be falling back to the PIC instead we fall back to the first IO-APIC. What difference does this make? We won't lose all the enhancements of the IO-APIC over the PIC. What comes to mind first is that, when using the PIC all non-MSI interrupts have to be dealt with by CPU0. You have no IRQ balancing, pinning and such things. > > Bjorn > > Stefan -- Stefan Assmann | SUSE LINUX Products GmbH Software Engineer | Maxfeldstr. 5, D-90409 Nuernberg Mail: sassmann@xxxxxxx | GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
