Bug 798628

Summary: can't suspend/resume Fedora 16 on Asus UX21 without custom script
Product: [Fedora] Fedora Reporter: Loris Santamaria <loris>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: gansalmon, hughsient, itamar, james, jforbes, jonathan, jskarvad, kernel-maint, kode54, madhu.chinakonda, michal, pknirsch, richard, spacewar
Target Milestone: ---Keywords: Patch
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: http://lkml.org/lkml/2011/11/30/456
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 697150 Environment:
Last Closed: 2012-11-14 20:48:13 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:

Description Loris Santamaria 2012-02-29 12:34:53 UTC 
+++ This bug was initially created as a clone of Bug #697150 +++

This is a fresh install of Fedora 16 x86_64 on an Asus UX21. All peripherals work perfectly except that suspending the laptop by closing the lid or pressing the suspend button consistently freezes the machine.

By following the advice on an Ubuntu forum ( http://ubuntuforums.org/showthread.php?t=1865577 ) I added this script to /etc/pm/sleep.d/20_custom_asus, and now suspend/resume works perfectly:

#!/bin/sh
EHCI_BUSES="0000:00:1d.0 0000:00:1a.0"
XHCI_BUSES="0000:03:00.0"
case "${1}" in
    hibernate|suspend)
        # Switch USB buses off
        for bus in $EHCI_BUSES; do
            echo -n $bus | tee /sys/bus/pci/drivers/ehci_hcd/unbind
        done
        for bus in $XHCI_BUSES; do
            echo -n $bus | tee /sys/bus/pci/drivers/xhci_hcd/unbind
        done
        ;;
    resume|thaw)
        # Switch USB buses back on
        for bus in $EHCI_BUSES; do
            echo -n $bus | tee /sys/bus/pci/drivers/ehci_hcd/bind
        done
        for bus in $XHCI_BUSES; do
            echo -n $bus | tee /sys/bus/pci/drivers/xhci_hcd/bind
        done
        ;;
esac
Comment 1 James 2012-05-05 13:54:36 UTC 
*** Bug 819128 has been marked as a duplicate of this bug. ***
Comment 2 James 2012-05-05 13:57:47 UTC 
Still in Fedora 17, kernel-3.3.4-4.fc17.x86_64. I see this also on my new notebook: suspend hangs just after turning off the hard disc. In my case, controllers are:

00:1a.0 USB Controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05)
00:1d.0 USB Controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05)
03:00.0 USB Controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04)

Using the above script works around the issue. Wonder what its state is upstream.
Comment 3 Jaroslav Škarvada 2012-05-09 13:06:49 UTC 
AFAIK xhci suspend support is in upstream kernel for a while, thus it should work out of the box. Some backtrace would probably help here, could you boot with kernel boot parameters (e.g. add to grub):
debug no_console_suspend ignore_loglevel

and try to suspend from text console (no X) by:
# pm-suspend
Comment 4 James 2012-05-09 13:40:19 UTC 
(In reply to comment #3)
> AFAIK xhci suspend support is in upstream kernel for a while, thus it should
> work out of the box. Some backtrace would probably help here, could you boot
> with kernel boot parameters (e.g. add to grub):
> debug no_console_suspend ignore_loglevel
> 
> and try to suspend from text console (no X) by:
> # pm-suspend

After further investigation, it turns out I only need to unbind the EHCIs, so xhci is probably not to blame. I'm currently following https://bugzilla.kernel.org/show_bug.cgi?id=42728 which might be related to what I see (suspend fails but I don't get memory corruption) -- I believe my notebook has the same chipset.

I understand a patch to resolve kbz 42728 was included in kernel 3.3.5, but I think it's Asus-specific so doesn't work on my machine. I've reported this upstream, so I'll probably send further feedback there. Thanks for pointing out the debug options -- I'll try them at the next opportunity.
Comment 5 Michal Jaegermann 2012-05-09 16:20:58 UTC 
(In reply to comment #3)
> AFAIK xhci suspend support is in upstream kernel for a while,

An extra "hook" script 
https://bugzilla.redhat.com/attachment.cgi?id=492542
from the original bug 697150 which was "cloned" here did not even bothered to
touch xhci devices (and also was not hardwiring PCI identifiers).  AFAICT I do not have anything served by xhci drivers so these developments are not really relevant as far as the original report is concerned.
Comment 6 James 2012-05-10 19:13:44 UTC 
It turns out on my machine, this is solved by the patch:

http://marc.info/?l=linux-kernel&m=133582194609000&w=2

solves this (linked via kbz 42728 above). Any chance this could be included in the Fedora kernels until it's included from the upstream?
Comment 7 Jaroslav Škarvada 2012-05-10 19:29:14 UTC 
James, thanks for info, reassigning to kernel guys for review / inclusion.
Comment 8 James 2012-05-10 19:34:41 UTC 
(In reply to comment #7)
> James, thanks for info, reassigning to kernel guys for review / inclusion.

Nice. According to comment on the kernel bugzilla, it should be in 3.3-stable soon anyway.
Comment 9 James 2012-05-19 23:48:06 UTC 
Well the patch for my particular case hasn't showed up in 3.3.6... any chance of it being included in the Fedora build until it's upstream?
Comment 10 Josh Boyer 2012-06-08 13:45:00 UTC 
The kernel bugzilla is still being worked.  Thus far it resulted in commit dbe9a2edd17d which will be in the 3.5-rc2 kernel (or a git snapshot after -rc1), but that isn't marked for stable yet.
Comment 11 Dave Jones 2012-10-23 15:25:24 UTC 
# Mass update to all open bugs.

Kernel 3.6.2-1.fc16 has just been pushed to updates.
This update is a significant rebase from the previous version.

Please retest with this kernel, and let us know if your problem has been fixed.

In the event that you have upgraded to a newer release and the bug you reported
is still present, please change the version field to the newest release you have
encountered the issue with.  Before doing so, please ensure you are testing the
latest kernel update in that release and attach any new and relevant information
you may have gathered.

If you are not the original bug reporter and you still experience this bug,
please file a new report, as it is possible that you may be seeing a
different problem. 
(Please don't clone this bug, a fresh bug referencing this bug in the comment is sufficient).
Comment 12 Michal Jaegermann 2012-10-24 00:41:08 UTC 
(In reply to comment #11)

> Kernel 3.6.2-1.fc16 has just been pushed to updates.
> This update is a significant rebase from the previous version.
> 
> Please retest with this kernel, and let us know if your problem has been
> fixed.

My original report was bug 697150 on Asus K52Jc (and for unclear reasons that was cloned to talk about Asus UX21).  I tested 3.6.2-1.fc16 on K52Jc and there indeed suspend and hibernate now work without a need of additional configuration and/or "hook" scripts such as detailed in bug 697150.

Once a weird thing happened in testing, though.  After an attempt to hibernate my laptop failed to do that but instead presented "unlock" alert.  After a password was supplied it went back to a desktop and immediately after that, without any
intervention, performed "hibernate".  After a resumption it went immediately back to a hibernate again, without asking for a password, and only on the second try to resume it started to behave like expected.  It looks like a weird race but I have no idea where really.  I was unable to repeat that.  Also in my older setup I never seen anything of that sort despite of rather extensive use of hibernation on this laptop.

No idea about UX21 and other Asus models.