I've got a HP EliteBook 8470p on which I installed Debian Wheezy in UEFI mode. With both the 3.2 kernel from Wheezy, as the 3.7.1 kernel from experimental, xhci fails to initialize and my USB mouse connected to one of these ports is not recognized at all. The USB3 ports work fine in Windows. [ 1.316248] xhci_hcd 0000:00:14.0: can't derive routing for PCI INT A [ 1.316251] xhci_hcd 0000:00:14.0: PCI INT A: no GSI [ 1.316253] [ 1.316277] xhci_hcd 0000:00:14.0: setting latency timer to 64 [ 1.316281] xhci_hcd 0000:00:14.0: xHCI Host Controller [ 1.316287] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 1 [ 1.316393] xhci_hcd 0000:00:14.0: cache line size of 64 is not supported [ 1.316395] xhci_hcd 0000:00:14.0: request interrupt 255 failed [ 1.316447] xhci_hcd 0000:00:14.0: USB bus 1 deregistered [ 1.316466] xhci_hcd 0000:00:14.0: can't derive routing for PCI INT A [ 1.316467] xhci_hcd 0000:00:14.0: init 0000:00:14.0 fail, -22 [ 1.316505] xhci_hcd: probe of 0000:00:14.0 failed with error -22 Full dmesg, lspci, lsusb and lsmod can be found here: http://artipc10.vub.ac.be/~frederik/uefi-xhci/ I found this report about the same problem on a HP Probook system: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1072918
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