XHCI device disconnect on S3 standby

[Matt DeVillier]

Greetings,

I'm unable to use any USB devices connected to an XHCI controller to resume from S3 standby, as something causes all connected devices to disconnect just prior to entering standby, as per the output of dmesg.

I've traced the relevant sections in the southbridge and ACPI source for my device (a haswell-based ChromeOS device with an Intel lynxpoint southbridge), but have been unable to find the culprit.

CONFIG_FINALIZE_USB_ROUTE_XHCI is set, as this device only has USB3 ports (4x), but having it set either way doesn't make a difference.  The usb_xhci_sleep_prepare() call doesn't seem to be the culprit, as commenting it out has no (positive) effect.

Resuming via the power switch or wake on lan work perfectly, so it's not a general resuming issue.

Appreciate any pointers on how to proceed

cheers,
Matt

[Duncan Laurie]

On Tue, May 27, 2014 at 3:17 PM, Matt DeVillier
 wrote:
> Greetings,
>
> I'm unable to use any USB devices connected to an XHCI controller to resume from S3 standby, as something causes all connected devices to disconnect just prior to entering standby, as per the output of dmesg.
>
> I've traced the relevant sections in the southbridge and ACPI source for my device (a haswell-based ChromeOS device with an Intel lynxpoint southbridge), but have been unable to find the culprit.
>
> CONFIG_FINALIZE_USB_ROUTE_XHCI is set, as this device only has USB3 ports (4x), but having it set either way doesn't make a difference.  The usb_xhci_sleep_prepare() call doesn't seem to be the culprit, as commenting it out has no (positive) effect.
>
> Resuming via the power switch or wake on lan work perfectly, so it's not a general resuming issue.
>
> Appreciate any pointers on how to proceed

USB/XHCI devices disconnecting in the kernel before the system goes to
suspend suggests it may be an intentional OS (via udev?) action.
Which distro are you using?

I think the panther mainboard has not been upstreamed yet so I assume
you are using a checkout from the chromium coreboot?  Or is this
pulling the chromium panther mainboard into the upstream coreboot?

Here are a few things to check:

- Is there an XHCI device visible (and set as enabled) in
/proc/acpi/wakeup output?

- When you go to suspend what does the kernel print about XHCI
controller itself?  (ignoring the devices for the moment)

I would expect to see lines like this before it actually goes to suspend:

xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI
xhci_hcd 0000:00:14.0: power state changed by ACPI to D3cold

And then after resume:

xhci_hcd 0000:00:14.0: power state changed by ACPI to D0
xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI

In an attempt to debug further it could help to send some additional output:

- dmesg after a suspend/resume cycle
- /sys/firmware/acpi/tables/DSDT (after run through iasl -d)  I don't
expect issues here if wake-on-lan is working, but worth a check.

Thanks,
-duncan

[Peter Stuge]

Matt DeVillier wrote:
> something causes all connected devices to disconnect just prior to
> entering standby, as per the output of dmesg.

I think it's the kernel doing this. There were some emails on
linux-usb either about this or at least about something similar.

xhci_hcd isn't really reliable yet.

//Peter