Hi, Maël Lavault <mael.lavault@xxxxxxxxxxxxxxxxxxx> writes: > Le 28 avr. 2017 15:57, "Maël Lavault" <mael.lavault@xxxxxxxxxxxxxxxxxxx >> a écrit : > On Fri, 2017-04-28 at 16:58 +0300, Mathias Nyman wrote: >> On 21.04.2017 11:08, Maël Lavault wrote: >> > On Tue, 2017-04-18 at 16:58 +0200, Maël Lavault wrote: >> > > Hi, >> > > >> > > I can't find how to reply to an old thread with majordomo, sorry >> > > for >> > > the inconvenience it might cause. >> > > >> > > I'm reposting an issue [0] that has been inactive for a few month >> > > but >> > > still present in kernel 4.10.10 on a Macbook pro 12,1. >> > > >> > > I can provide more informations if needed but the issue is >> > > explained >> > > in >> > > details in the bugzilla issue. >> > > >> > > Thanks. >> > > >> > > --------------- >> > > Hi list, >> > > >> > > 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. >> > > >> > > I have attached some log files on the bugzilla issue tracker [1] >> > > (they >> > > are >> > > to big for the ML I think). >> > > >> > > [1] https://bugzilla.kernel.org/show_bug.cgi?id=115741 >> > > >> > > >> > > Olliver >> > > >> > > >> > > >> > > [0] http://thread.gmane.org/gmane.linux.usb.general/139697 >> > >> > I updated to fedora 26 with kernel 4.11.0-rc7 and the issue is >> > still >> > present. >> >> 4.11-rc7 should have xhci tracepoints installed. >> Could you take some traces at boot with most recent kernel you got. >> >> xhci traces for boot can be enabled by adding "trace_event=xhci-hcd" >> to >> your kernel cmdline >> >> Traces should then appear in /sys/kernel/debug/tracing/trace >> >> -Mathias > > Thanks ! I'll try to do that, but it's utterly difficult since each > keypress takes between 5 and 10 seconds due to this bug ... > > So I tried it and I cannot access the trace. Are the trace persisted > across reboot ? Since all 4.11 kernel freeze on the login page I have > no other choice but rebooting on a old 4.10 kernel to look at the > trace. You could SSH from a different machine, no? tracepoints don't persist across reboots, AFAICT. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
