On Mon, 21 Oct 2019 20:14:19 +0200, Ross Zwisler wrote: > > Hi, > > I'm hitting an issue on a Broadwell based Chromebox that appears to be > related to the XHCI_SPURIOUS_WAKEUP quirk. > > Here are the reproduction steps: > > 1) Start with a fully booted system on a recent kernel. I've been > testing with v5.4-rc4. > > 2) Gracefully shut down the system, either with 'halt -p' or by > pushing the power button. This causes the XHCI_SPURIOUS_WAKEUP quirk > to be applied on shutdown via xhci_shutdown(). > > 3) Quickly (within a few seconds) restart the system using the power button. > > 4) After the system restarts, we end up in a state where USB 2.0 > devices work fine, but all USB 3.X devices don't work at all. The > kernel never sees them being inserted, we never call usb_new_device() > or any other USB related kernel code. This state persists for the > duration of the boot on all ports for the internal USB 3.0 hub, and is > independent of which devices were plugged into the hub during boot. > > Attaching a USB analyzer between the USB hub and the USB 3.0 device, I > see that the hub sees the device insertion, but disables SuperSpeed. > >From then on all the USB analyzer sees is garbage, and the connection > never successfully drops down to USB 2.0. > > Disabling the above mentioned quirk prevents this from happening, and > it also doesn't happen if the system is warm rebooted or if the system > is left off for a longer period of time (~10 seconds or more) before > powering back on. > > So, a few questions: > > 1) I'm running on a Chromebox using Coreboot. Does anyone have a > BIOS-based BDW system to see if they can reproduce it there?
I'll poke a colleague who has a Lenovo laptop with BDW. > 2) What is the appropriate way to deal with this issue? From looking > at the history of the quirk, it looks like it was put in for good > reasons and that it still needs to be there for other systems. > Assuming other vendors' systems don't reproduce the above issue, > should I just exclude Google made systems from the quirk? Something > else? I suspected the symptom rather being XHCI_SPURIOUS_REBOOT, judging from the description, but it's buggy BIOS thingy, so everything may happen... I'd take an approach limiting the change to specific platforms (Google) via DMI match or such, as the device in question is really old and has a high potential regression risk. But just my $0.02. thanks, Takashi
