Bug 623573
| Summary: | xhci doesn't support power management, breaking suspend | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | David Kovalsky <dkovalsk> |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | 19 | CC: | anton, arozansk, awilliam, awithers, benl, dougsland, dzickus, gansalmon, gong.chen, itamar, jane.lv, jforbes, jlv, jonathan, jskarvad, jvillalo, kernel-maint, luyu, madhu.chinakonda, maxim, myllynen, oliver.henshaw, ovasik, pcfe, qcai, rdoty, rhughes, syeghiay, thorbjorn, walicki |
| Target Milestone: | --- | Keywords: | CommonBugs |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | https://fedoraproject.org/wiki/Common_F14_bugs#usb_3.0 | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 608343 | Environment: | |
| Last Closed: | 2013-04-23 19:42:47 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 608343 | ||
| Bug Blocks: | 551128 | ||
|
Description
David Kovalsky
2010-08-12 08:17:53 UTC
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 -- 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? |