Comment 32 for bug 1668105

Revision history for this message
In , oliver (oliver-linux-kernel-bugs) wrote :

Created attachment 211371
Dmesg output with broken usb

I have a Apple Inc. MacBookPro11,1 (with the most recent 'bios': BIOS MBP111.88Z.0138.B16.1509081438 09/08/2015).

At the beginning, USB worked normally. After a while (and after newer kernel versions released by debian?) things started to act strangely. For one, the bios/efi boot takes a very long time (probably due to the same reason I describe later) just to get to the bootloader/grub. Likley resetting and probing for USB ports/mass storage. When grub finally pops up, I can use the (internal USB based keyboard) normally to select a grub entry etc.

Booting the kernel then works reasonably fine, until it loads the xhci module.
It spews some messages in dmesg (taking some 15 seconds) and only then, the keyboard starts to work again.

The log is filled with messages like:
[ 7.248479] xhci_hcd 0000:00:14.0: Command completion event does not match command
[ 7.248495] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 12.256347] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 12.256363] usb 1-2: hub failed to enable device, error -62
[ 17.264166] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
(followed by USB hub/device enumeration)

I've tried several combinations and quirks, updating to the latest rc kernels since 3.16 (am on 4.5.0 right now) and it only seems to get worse.

Last year, on the 3.x series of kernels occasionally after a reboot the 'bios' would go through quickly and fine and also no problems loading the module and logging in. But now it always fails.

Additionally it (may or may not) seems to cause the internal usb card reader to not even show up almost all of the time, though under OSX it works fine. There is/was a known issue with this cardreader where it would disappear after a suspend.

Adding various seemingly related intel usb3 quirks I had no change, as I think all of them are already applied to this chipset.

I'm guessing that somehow the usb chipset has some configuration option miss-set (which persists over reboots/power down) and the driver doesn't quite understand it.

Unfortunately it seems that this chipset does not work in pure USB2.0 (ehci) mode and needs the xhci module to work at all, so even falling to USB2 is no option. Also disconnecting all USB perhipials is nearly impossible as the touchpad, bluetooth cardreader and keyboard are internally all wired to USB.

I'm attaching 3 dmesg logs with various kernels and levels of debugging information. I tried to google for errors from these logs, but to no avail.