Bug 52591
Summary: | xhci module fails when booting in UEFI mode | ||
---|---|---|---|
Product: | Drivers | Reporter: | frederik |
Component: | PCI | Assignee: | drivers_pci (drivers_pci) |
Status: | RESOLVED CODE_FIX | ||
Severity: | normal | CC: | bjorn, hare |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 3.2 - 3.7 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
3.7+ dmesg
lspci -vv dmesg 3.8.0-rc7 lspci -vv pci: do not try to assign irq 255 dmesg 3.8.0-rc7-fixed lspci -vv acpi dump |
Description
frederik
2013-01-11 19:37:47 UTC
Created attachment 93621 [details] 3.7+ dmesg From http://artipc10.vub.ac.be/~frederik/uefi-xhci/dmesg Created attachment 93631 [details] lspci -vv From http://artipc10.vub.ac.be/~frederik/uefi-xhci/lspci Created attachment 93651 [details]
dmesg 3.8.0-rc7
Dmesg from stock 3.8.0-rc7.
Created attachment 93661 [details]
lspci -vv
lspci -vv from 3.8.0-rc7
Created attachment 93671 [details]
pci: do not try to assign irq 255
Proposed patch.
Created attachment 93681 [details]
dmesg 3.8.0-rc7-fixed
Dmesg after patching kernel.
Created attachment 93691 [details]
lspci -vv
lspci -vv from the patched kernel.
The proposed patch makes the system boot and seems to work as expected. However, I'm not sure here if that's a generic fix (irq 255 has a questionable existence anyway) or if it should move into a quirk. Created attachment 93731 [details]
acpi dump
Output of acpidump from the system.
And here is the ACPI dump for completeness. As you can see, the xhci device does not appear in the ACPI tables, hence the fallback to the old, supposedly obsolete method for selecting INTx. The curious thing here is that when booted with CSM only the BIOS assigns IRQ 10 to the device, so we're hitting a different branch in drivers/acpi/pci_irq.c: /* Interrupt Line values above 0xF are forbidden */ if (dev->irq > 0 && (dev->irq <= 0xF) && (acpi_isa_irq_to_gsi(dev->irq, &dev_gsi) == 0)) { dev_warn(&dev->dev, "PCI INT %c: no GSI - using ISA IRQ %d\n", pin_name(pin), dev->irq); acpi_register_gsi(&dev->dev, dev_gsi, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW); } else { dev_warn(&dev->dev, "PCI INT %c: no GSI\n", pin_name(pin)); } return 0; hence these devices work when booted with CSM only. Which, of course, leads to an alternative fix: diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c index 68a921d..d5db256 100644 --- a/drivers/acpi/pci_irq.c +++ b/drivers/acpi/pci_irq.c @@ -469,6 +469,7 @@ int acpi_pci_irq_enable(struct pci_dev *dev) } else { dev_warn(&dev->dev, "PCI INT %c: no GSI\n", pin_name(pin)); + dev->irq = -1; } return 0; } Except that the '-1' should be a '0'. Of course. This is working now with recent Linux kernels thanks to this commit https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=00eed9c814cb8f281be6f0f5d8f45025dc0a97eb |