Shaohua Li wrote: > On Mon, Jan 12, 2009 at 07:09:25PM +0800, Stefan Assmann wrote: >> Hi Len, >> >> 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. >>> >>> I left the other parts of the quirk intact - so at the moment >>> on one of the quirked machines, you'll see >>> >>> PCI quirk: reroute interrupts for... >>> >>> but will not see >>> >>> pci irq %d -> rerouted to legacy >>> >>> as the quirk is effectively disabled. >>> >>> I had difficulty trying to port this patch to the new pci_irq.c >>> because fundamentally I don't understand what it is trying >>> to do, and why. >> 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 >> >> This behavior is not necessary during normal operation as the IRQ is >> handled by the non-primary IO-APIC itself. Now imagine what happens if >> these Boot Interrupts would occur during normal operation. You'd see >> spurious IRQs on your primary IO-APIC which, in the worst case, will >> bring down the interrupt line they occur on! Every device that shares this >> interrupt line will fail when this happens. >> >> Why can these IRQ lines be brought down by Boot Interrupts? Because >> there's no handler installed on the primary IO-APIC IRQ line that can >> take care of them and after too many unhandled IRQs the line will be shut >> down by the kernel. >> >> What this quirk does: >> It installs the interrupt handler on the primary IO-APICs interrupt line >> instead of the (original) non-primary IO-APICs interrupt line, keeping >> the original interrupt line masked. This guarantees that for every IRQ >> arriving at the non-primary IO-APIC a Boot Interrupt is generated _and_ >> handled properly. >> >> Note: You need this quirk if you mask your interrupts during handling. > So a device can generate interrupt from two irqs. And we can get the irq > number for the routing table. Can we extend the irq mechanism and > automatically register the interrupt handler for the two irqs? This would not solve the problem of asserting 2 different interrupt lines, in the masked interrupt handling case, for 1 interrupt request. The result would be that the ISR is called twice and at the second call you can't be sure that the device hasn't already been serviced. > > Thanks, > Shaohua 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
