Bug 94261 - usb ports working only with "pci=noacpi"
Summary: usb ports working only with "pci=noacpi"
Status: CLOSED WILL_NOT_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: Other (show other bugs)
Hardware: x86-64 Linux
: P1 high
Assignee: acpi_other
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-04 12:34 UTC by Valerio Vanni
Modified: 2015-08-21 06:33 UTC (History)
2 users (show)

See Also:
Kernel Version: 3.14.34
Subsystem:
Regression: No
Bisected commit-id:


Attachments
kernel config (96.73 KB, text/plain)
2015-03-04 12:34 UTC, Valerio Vanni
Details
dmesg normal (27.92 KB, text/plain)
2015-03-04 12:34 UTC, Valerio Vanni
Details
dmesg pcinoacpi (29.47 KB, text/plain)
2015-03-04 12:35 UTC, Valerio Vanni
Details
lspci normal (4.92 KB, text/plain)
2015-03-04 12:35 UTC, Valerio Vanni
Details
lspci pcinoacpi (5.62 KB, text/plain)
2015-03-04 12:35 UTC, Valerio Vanni
Details
lsusb pcinoacpi (242 bytes, text/plain)
2015-03-04 12:36 UTC, Valerio Vanni
Details
acpidump (215.14 KB, text/plain)
2015-03-16 16:19 UTC, Valerio Vanni
Details
acpidump with normal start of 3.19.2 (usb not working) (215.50 KB, text/plain)
2015-03-19 11:52 UTC, Valerio Vanni
Details
dmesg normal start 3.19.2 (28.79 KB, text/plain)
2015-03-20 11:00 UTC, Valerio Vanni
Details

Description Valerio Vanni 2015-03-04 12:34:24 UTC
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.
Comment 1 Valerio Vanni 2015-03-04 12:34:54 UTC
Created attachment 168931 [details]
dmesg normal
Comment 2 Valerio Vanni 2015-03-04 12:35:16 UTC
Created attachment 168941 [details]
dmesg pcinoacpi
Comment 3 Valerio Vanni 2015-03-04 12:35:37 UTC
Created attachment 168951 [details]
lspci normal
Comment 4 Valerio Vanni 2015-03-04 12:35:59 UTC
Created attachment 168961 [details]
lspci pcinoacpi
Comment 5 Valerio Vanni 2015-03-04 12:36:17 UTC
Created attachment 168971 [details]
lsusb pcinoacpi
Comment 6 Valerio Vanni 2015-03-09 08:24:45 UTC
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.
Comment 7 Aaron Lu 2015-03-13 02:49:30 UTC
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.
Comment 8 Valerio Vanni 2015-03-13 19:34:42 UTC
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.
Comment 9 Aaron Lu 2015-03-16 03:01:07 UTC
Please attach acpidump:
# acpidump > acpidump.txt
Comment 10 Valerio Vanni 2015-03-16 16:19:52 UTC
Created attachment 170791 [details]
acpidump

It's the same as with the pci=noacpi switch.
Comment 11 Aaron Lu 2015-03-19 07:17:52 UTC
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?
Comment 12 Valerio Vanni 2015-03-19 11:51:37 UTC
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.
Comment 13 Valerio Vanni 2015-03-19 11:52:14 UTC
Created attachment 171181 [details]
acpidump with normal start of 3.19.2 (usb not working)
Comment 14 Aaron Lu 2015-03-20 02:01:03 UTC
(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.
Comment 15 Valerio Vanni 2015-03-20 11:00:33 UTC
Created attachment 171471 [details]
dmesg normal start 3.19.2
Comment 16 Aaron Lu 2015-03-31 05:22:13 UTC
+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.
Comment 17 Aaron Lu 2015-08-20 08:57:29 UTC
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.
Comment 18 Valerio Vanni 2015-08-20 20:24:01 UTC
I don't have that machine anymore, so I can't test.
Comment 19 Aaron Lu 2015-08-21 06:33:35 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.