problem with XHCI_SPURIOUS_WAKEUP quirk

problem with XHCI_SPURIOUS_WAKEUP quirk

[Ross Zwisler]

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?

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?

Thanks,
- Ross

Re: problem with XHCI_SPURIOUS_WAKEUP quirk

[Takashi Iwai]

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