On Tue, May 27, 2014 at 3:17 PM, Matt DeVillier
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
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
- 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.