Red Hat Bugzilla – Bug 623573
xhci doesn't support power management, breaking suspend
Last modified: 2014-03-31 19:45:45 EDT
Same story for Fedora 13 kernel-2.6.33.6-147.2.4.fc13.x86_64 pm-utils-1.2.6.1-1.fc13.x86_64 Unloading the xhci module allows the notebook to suspend. Though it doesn't come back, but that's a different problem. +++ This bug was initially created as a clone of Bug #608343 +++ I'm trying to suspend, but I'm unable to. [root@kovinek ~]# pm-is-supported --suspend [root@kovinek ~]# echo $? 0 [root@kovinek ~]# pm-suspend [root@kovinek ~]# echo $? 1 The system "blinks" from graphical to text and immediately comes back. /var/log/messages: kernel: Freezing user space processes ... (elapsed 0.00 seconds) done. kernel: Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. kernel: Suspending console(s) (use no_console_suspend to debug) kernel: pm_op(): usb_dev_suspend+0x0/0x20 returns -2 kernel: PM: Device usb3 failed to suspend: error -2 kernel: PM: Some devices failed to suspend kernel: Restarting tasks ... done. --- Additional comment from dkovalsk@redhat.com on 2010-06-26 17:59:40 EDT --- Created an attachment (id=427147) pm-suspend.log --- Additional comment from dkovalsk@redhat.com on 2010-06-26 18:01:21 EDT --- FYI - same behavior with hibernate --- Additional comment from jskarvad@redhat.com on 2010-06-30 05:15:05 EDT --- The problem seems to be in USB3 xhci module. Suspend/Resume works with a workaround on Lenovo W510. The xhci USB 3.0 module must be unloaded before suspend, because it seems the suspend method is not implemented in xhci yet. --- Additional comment from jskarvad@redhat.com on 2010-06-30 05:18:52 EDT --- It is possible to force unloading of xhci module by adding config file (with arbitrary name, e.g xhci) to /etc/pm/config.d with content: SUSPEND_MODULES="xhci" But for me this looks as not clean solution, thus this bug should be probably reassigned to kernel. --- Additional comment from myllynen@redhat.com on 2010-06-30 06:24:13 EDT --- I'm seeing exactly the same issue with HP 8540w and also there unloading xhci (which is used by nobody) fixes it. This is rather bad for users of recent, we definitely need some technical notes. --- Additional comment from jskarvad@redhat.com on 2010-06-30 06:47:38 EDT --- Upstream kernel bugzilla for it: https://bugzilla.kernel.org/show_bug.cgi?id=16153 --- Additional comment from mjg@redhat.com on 2010-07-06 10:59:03 EDT --- I'm proposing a patch to disable module autoloading of this driver. --- Additional comment from luyu@redhat.com on 2010-07-06 11:23:24 EDT --- Not sure if the patch http://kerneltrap.org/mailarchive/linux-usb/2010/5/13/6260980 works?
What's the expected outcome of this bug? AFAIK upstream is still working on a solution. The earliest would be 2.6.37 but I doubt it, probably 2.6.38. I am not sure those kernels will ever make it into F13. Therefore I don't expect this to be resolved until F15 earliest. But not loading the module should allow suspend/resume to work. Cheers, Don
Fair enough. Switching the bug against rawhide to track. Thanks for the info, Don! (loading/unloading the module during suspend indeed does function as a workaround)
So for F14 we 'fixed' this by disabling xhci support by default and adding a kernel parameter to fix it. Honestly, contrary to the comments in the parent bug, I would argue that adding a suspend quirk requiring this module to be reloaded around a suspend is much cleaner than making people choose between USB 3.0 support and suspend/resume support. Could we put a quirk for the module in pm-utils instead of just using a big hammer on the problem? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #3) > Honestly, contrary to the comments in the parent bug, I would argue that adding > a suspend quirk requiring this module to be reloaded around a suspend is much > cleaner than making people choose between USB 3.0 support and suspend/resume > support. Could we put a quirk for the module in pm-utils instead of just using > a big hammer on the problem? I think backporting the kernel patch is a better idea, as quirks do build up in pm-utils, and then patches never go upstream. It's much better to fix the driver. Plus, weird things might happen to storage devices attached to usb3, that suddenly get the xhci driver ripped from under their feet.
"I think backporting the kernel patch is a better idea" I agree, now it exists =) When I wrote that comment I thought it was further out from upstream acceptance. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
> So for F14 we 'fixed' this by disabling xhci support by default and adding a > kernel parameter to fix it. I wish a printk letting us know the module was disabled was part of that workaround. I'll grant that once you know what you are looking for this is easily searched and resolved but seeing xhci_hcd loaded without a single line in dmesg was more confusing than it needed to be.
*** Bug 815906 has been marked as a duplicate of this bug. ***
I still need a script in /etc/pm/sleep.d to unbind the xhci_hcd and ehci_hcd drivers before suspend in order to successfully put my laptop to sleep. I'm not sure whether that's a bug in the existing xhci_hcd pm implementation or a bug in my laptop, but the nets are riddles with similar cases. Does anyone have an idea in how to get this fixed upstream? It would be great not having to remember to migrate this script at every reinstall I do :)
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Is this still a problem with 3.9 based F19 kernels?
justin: well, the 'xhci' module doesn't appear to exist any more. I don't know what module supports USB 3.0 controllers these days, but there's a USB 3.0 controller in this system, I can plug a USB 3.0 Flash drive into it and I see "SuperSpeed" (== 3.0) in the kernel logs, and I can also suspend/resume the system. So my bet would be 'no', but I'm not intimately familiar with the actual code history here, I'm just going on a look at what the alleged symptoms of the bug are/were.
Hi Adam, config-generic:CONFIG_USB_XHCI_HCD=y the xhci driver is built into the fedora kernel, hence no module. :-) I have done a bunch of usb3 suspend/resume testing for RHEL-6 (which is based on 3.4 and later) and everything seems to work. RHEL-6 doesn't support runtime suspend, so I can't vouch for that. I think everything should work correctly for Fedora 19. If not I can poke at it some more. Cheers, Don
Like I said, on a dumb monkey test level it works fine. I have a USB 3.0 controller, it appears to be working in USB 3.0 mode, and I can support/resume. Case closed?