Bug 94261
Summary: | usb ports working only with "pci=noacpi" | ||
---|---|---|---|
Product: | ACPI | Reporter: | Valerio Vanni (valerio.vanni) |
Component: | Other | Assignee: | acpi_other |
Status: | CLOSED WILL_NOT_FIX | ||
Severity: | high | CC: | aaron.lu, bjorn |
Priority: | P1 | ||
Hardware: | x86-64 | ||
OS: | Linux | ||
Kernel Version: | 3.14.34 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
kernel config
dmesg normal dmesg pcinoacpi lspci normal lspci pcinoacpi lsusb pcinoacpi acpidump acpidump with normal start of 3.19.2 (usb not working) dmesg normal start 3.19.2 |
Created attachment 168931 [details]
dmesg normal
Created attachment 168941 [details]
dmesg pcinoacpi
Created attachment 168951 [details]
lspci normal
Created attachment 168961 [details]
lspci pcinoacpi
Created attachment 168971 [details]
lsusb pcinoacpi
Today or tomorrow that PC will be sold, so I don't have much time to test. So far I didn't found any solution. That's not a problem, since this will be sold with Windows 8. If I'll have another identical machine between my hands (perhaps next month), I could test further on that. The EHCI host controller 00:1d.0 doesn't get enumerated in the default case and the XHCI host controller 00:14.0 doesn't get probed by the driver for some reason. Is there a BIOS update from the vendor? Bug closed for the moment, please re-open when you have access to this machine next month. Plans have been changed, I have still the machine for some day. If there's some idea, I can test. After the issue came up, I searched and found a new BIOS. I installed it, but it didn't fix anything. Please attach acpidump: # acpidump > acpidump.txt Created attachment 170791 [details]
acpidump
It's the same as with the pci=noacpi switch.
I don't see why without pci=noacpi, the USB2 host controller device 00:1d.0 doesn't get enumerated. Is it also the case for a recent kernel, say v3.19? As I said in the first message, newer kernel versions don't work at all. I just tried 3.19.2 and it behaves like 3.19 and 3.18.8: with a normal start, USB ports don't work. With a "pci=noacpi" start, the kernel crashes. It crashes with a "VFS: unable to mount root", it seems not to be able to find disks. I put an acpidump.txt with a normal start of 3.19.2. Created attachment 171181 [details]
acpidump with normal start of 3.19.2 (usb not working)
(In reply to Valerio Vanni from comment #12) > As I said in the first message, newer kernel versions don't work at all. > I just tried 3.19.2 and it behaves like 3.19 and 3.18.8: with a normal > start, USB ports don't work. Please attach its dmesg. Created attachment 171471 [details]
dmesg normal start 3.19.2
+Bjorn My understanding is that, no matter if ACPI is involved, the PCI devices are probed by the same: pci_scan_child_bus function. So I don't see why the 0000:00:1d.0 USB controller PCI device would only be probed when pci=noacpi is added to the cmdline. Bjorn, do you have any ideas? Thanks. Hi Valerio, I guess this is still the case in later kernels(if pci=noacpi is not added to cmdline, the 0000:00:1d.0 USB controller PCI device isn't enumerated)? If so, I will write an email to mailing list for more comments. I don't have that machine anymore, so I can't test. Then I'll close it for now, if you want to dig further when you have the machine, please let me know and I'll write an email to mailinglist for comments. |
Created attachment 168921 [details] kernel config The machine is: LENOVO 90BX0018IX/Aptio CRB, BIOS O07KT49AUS 12/18/2014 OS is a Debian Wheezy amd64. The issue is that USB ports work only starting the kernel with "pci=noacpi" parameter. Without it, nothing plugged into usb ports is detected. In particular, "lsusb" returns "unable to initialize libusb: -99". The same happens with a 3.13.11 kernel (same config). I've tried newer kernels (3.18.8, 3.19) and they show the same issue. With the difference that, with "pci=noacpi" they don't start at all. I attach some diagnostic with and without the switch.