On Mon, Mar 13, 2017 at 09:19:02AM +0100, Stefan Assmann wrote: > On 13.03.2017 03:20, Bjorn Helgaas wrote: > > On Fri, Feb 10, 2017 at 12:45:17PM +0100, Stefan Assmann wrote: > >> When checking for boot interrupts and PRT index is zero avoid doing > >> any interrupt rerouting since the code currently does not handle > >> determining the IRQ via _CRS method. > >> > >> Fixes: > >> https://bugzilla.kernel.org/show_bug.cgi?id=43074 > >> > >> Signed-off-by: Stefan Assmann <sassmann@xxxxxxxxx> > >> --- > >> drivers/acpi/pci_irq.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c > >> index c576a6f..6ecbde0 100644 > >> --- a/drivers/acpi/pci_irq.c > >> +++ b/drivers/acpi/pci_irq.c > >> @@ -280,7 +280,7 @@ static int bridge_has_boot_interrupt_variant(struct pci_bus *bus) > >> static int acpi_reroute_boot_interrupt(struct pci_dev *dev, > >> struct acpi_prt_entry *entry) > >> { > >> - if (noioapicquirk || noioapicreroute) { > >> + if (noioapicquirk || noioapicreroute || entry->index == 0) { > >> return 0; > >> } else { > >> switch (bridge_has_boot_interrupt_variant(dev->bus)) { > > > > I don't understand acpi_reroute_boot_interrupt() in general. > > > > I think I understand the chipset functionality, i.e., the Intel > > 6700PXH contains two IOAPICs, each with 16 interrupt inputs, and if an > > interrupt is asserted while that input is masked in the IOAPIC, the > > 6700PXH generates an INTx ASSERT message on the PCIe bus. > > > > What I don't understand is what the "correct" way of handling this is. > > I assume the intent was *not* that the OS should have device-specific > > code to deal with this. > > Boot interrupts are a mechanism to forward IRQs to the primary PIC/APIC, > this is done via the INTx messages. The idea is to provide support for > legacy OSes that do not support APICs. It probably was meant to be a > firmware only thing, but the problem at hand is this: > The condition for generating boot interrupts is, the input being masked > while an interrupt is asserted (on a non-primary IO-APIC). As you > already stated. > If this happens _and_ the interrupt line, the INTx messages get forwarded > to, already has an IRQ handler registered then there's no handler to > take care of those forwarded IRQs and eventually the kernel may > falsely shutdown that interrupt line. Because of too many lost > interrupts. > Sidenote, if there's no IRQ handler registered on that interrupt line, > the input is already masked and the boot interrupt silently disappears. > > > Is it a case of the BIOS doing something wrong? Is ACPI just not > > expressive enough to describe this hardware behavior? > > To be honest I'm not sure. The simplest of solutions would have been to > implement an on/off switch for boot interrupts in the chipset, but > unfortunately we did not find such a thing. So the solution we worked > out was to move the interrupt handler to the legacy interrupt line. Rafael, do you have any hints about ways to disable this boot interrupt thing? All the devices that use this irq->reroute_variant seem to be Intel devices. It just seems wrong to me to unconditionally override the _PRT entry when the hardware behavior is conditional on the APIC input being masked. If we can't disable the boot interrupt thing, could we use a DMI switch to special-case this M2N-LR system? The fact that entry->index is zero in this case seems like a coincidence that we shouldn't rely on. But I don't feel like I fully understand _PRT entries, so maybe it's not. Bjorn -- 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
