| View previous topic :: View next topic |
| Author |
Message |
freifunk_connewitz
Apprentice
Joined: 08 Feb 2006
Posts: 236
|
 Posted: Wed Apr 15, 2020 7:32 pm Post subject: [SOLVED] kernel 5.4.28 regression: XHCI breaks suspend |
 |
|
hi
after a kernel update from 4.19.82 to 5.4.28 my system won't suspend anymore. The error messages:
| Quote: | Apr 15 21:14:11 red kernel: xhci_hcd 0000:38:00.0: WARN: xHC save state timeout
Apr 15 21:14:11 red kernel: PM: suspend_common(): xhci_pci_suspend+0x0/0xd0 returns -110
Apr 15 21:14:11 red kernel: PM: pci_pm_suspend(): hcd_pci_suspend+0x0/0x20 returns -110
Apr 15 21:14:11 red kernel: PM: dpm_run_callback(): pci_pm_suspend+0x0/0x130 returns -110
Apr 15 21:14:11 red kernel: PM: Device 0000:38:00.0 failed to suspend async: error -110
Apr 15 21:14:11 red kernel: PM: Some devices failed to suspend, or early wake event detected
|
It looks like XHCI USB driver in kernel is blocking suspend - like it has been doing already back in 2013 (according to some internet findings).
I don't think it is about the recent switch to elogind over ConsoleKit: I removed ConsoleKit (and kept pm-utils, because whatever the news messages said, without pm-utils there is no suspend at all and no alternative was mentioned). But when I boot back into kernel 4.19.82 that has the same XHCI-related settings as the 5.4.28, suspend works flawlessly. Booting back to 5.4.28: suspend fails.
This problem might be handled if I bake the kernel new and build all the XHCI stuff as modules and then add a script to /etc/pm/sleep.d that removes and reinserts modules xhci_pci and hcd_pci during suspend/resume. But I wonder why the older kernel was successfully suspending before. Was there any patching regarding the problem that did not make it into version 5?
The hardware causing the trouble according to lspci: USB controller: Intel Corporation JHL7540 Thunderbolt 3 USB Controller [Titan Ridge 4C 2018] (rev 06)
Last edited by freifunk_connewitz on Sat Apr 18, 2020 7:33 pm; edited 1 time in total |
|
| Back to top |
|
 |
freifunk_connewitz
Apprentice
Joined: 08 Feb 2006
Posts: 236
|
| Posted: Fri Apr 17, 2020 11:15 am Post subject: |
|
|
Also with xhci as modules suspend2ram fails.
When I unload the xhci modules, in order:
| Code: |
modprobe -r xhci_plat_hcd
modprobe -r xhci_pci
modprobe -r xhci_hcd
|
s2ram succeeds.
After resuming, I reload the above modules. The funny thing is, for the next suspend2ram to succeed I DO NOT need to unload these modules. It seems like unloading them once told the XHCI driver to behave.
Am I completely alone with this phenomenon and have to blame it on the hardware being not fully supported? Or is this something kernel devs should be bugged with?
(BTW: I switched from sys-power/pm-utils to sys-power/suspend, that's why no 'pm-suspend' but 's2ram' command to suspend) |
|
| Back to top |
|
|
freifunk_connewitz
Apprentice
Joined: 08 Feb 2006
Posts: 236
|
| Posted: Sat Apr 18, 2020 7:33 pm Post subject: |
|
|
weird,
after some more reboots suspend works fine, afer the third reboot even the suspend button in plasma returned. marking as solved. |
|
| Back to top |
|
|
|
Kernel & Hardware
