Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
Bug 623573 - xhci doesn't support power management, breaking suspend
xhci doesn't support power management, breaking suspend
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
19
All Linux
high Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs
: 815906 (view as bug list)
Depends On: 608343
Blocks: 551128
  Show dependency treegraph
 
Reported: 2010-08-12 04:17 EDT by David Kovalsky
Modified: 2014-03-31 19:45 EDT (History)
30 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 608343
Environment:
Last Closed: 2013-04-23 15:42:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Kovalsky 2010-08-12 04:17:53 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?
Comment 1 Don Zickus 2010-10-05 17:22:32 EDT
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
Comment 2 David Kovalsky 2010-10-06 04:17:18 EDT
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)
Comment 3 Adam Williamson 2010-11-01 20:38:08 EDT
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
Comment 4 Adam Williamson 2010-11-01 20:38:26 EDT

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 5 Adam Williamson 2010-11-01 20:43:50 EDT

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 6 Richard Hughes 2010-11-03 05:23:52 EDT
(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.
Comment 7 Adam Williamson 2010-11-03 11:56:15 EDT
"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
Comment 8 Anduin Withers 2011-05-02 23:13:21 EDT
> 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.
Comment 9 Maxim Burgerhout 2012-05-04 08:41:01 EDT
*** Bug 815906 has been marked as a duplicate of this bug. ***
Comment 10 Maxim Burgerhout 2012-05-04 11:04:03 EDT
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 :)
Comment 11 Fedora End Of Life 2013-04-03 14:09:25 EDT
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
Comment 12 Justin M. Forbes 2013-04-05 12:59:57 EDT
Is this still a problem with 3.9 based F19 kernels?
Comment 13 Adam Williamson 2013-04-05 15:17:41 EDT
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.
Comment 14 Don Zickus 2013-04-05 15:27:57 EDT
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
Comment 15 Adam Williamson 2013-04-05 15:34:43 EDT
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?

Note You need to log in before you can comment on or make changes to this bug.