Kernel Bug Tracker – Bug 38982
Suspend to RAM works only 1-3 times
Last modified: 2013-12-11 03:44:29 UTC
MSI E350IA-E45 (AMD Fusion E-350 Zacate), 2Gb RAM, 500Gb HDD, Arch x86_64.
# uname -a
Linux xbmc-pc 3.0.0-rc6-mainline #1 SMP PREEMPT Fri Jul 8 07:58:00 NOVST 2011 x86_64 AMD E-350 Processor AuthenticAMD GNU/Linux
I am trying to get suspend to ram working. When suspending the machine second or third time it hangs with black screen an green power led. I need to unplug the power cord and back it again to bring the machine back up.
I tried 2.6.38, 2.6.39 and now 3.0-rc6 kernel, but without success. The unbinding usb-ports and unloading sound, video, network modules does not help.
Also I have debugged DSDT table and replace it with grub2 at boot.
The bios for mb is the latest version.
The logs are for one one successful suspend and one unsuccessful.
Created attachment 64972 [details]
Created attachment 64982 [details]
lspci -Q -vv
Created attachment 64992 [details]
Created attachment 65002 [details]
got the same issue on:
2.6.39-ARCH #1 SMP PREEMPT Sat Jul 9 14:57:41 CEST 2011 x86_64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux
lspci -Q -vv
I also tried the latest vanilla stable kernel - without success. Before upgrading kernel to any of *.39 version suspend to RAM was working correctly. Thank you in advance!
Have there been any updates on this one? This one renders laptop use extremely cumbersome and is affecting a sizable user population. See:
(Google for AMD Fusion suspend, or something to that effect)
FWIW, I vote to escalate this bug since it has been around for quite a few versions. Here are things I tried on HP dm1-4142nr using Ubuntu 12.04 64bit (HD6320 APU with fglrx driver, using for the most part -lowlatency kernel, currently version 3.2.0-35):
*Tried uswsusp as well as pm-utils
*Tried various acpi_osi flags, including Linux as well as every Windows variant found in dsdt
*Tried all the kernel flags I could find (acpi=s3_bios,s3_mode,etc. pci=nocrs hpet=disable etc.) and combination thereof
*Decompiled dsdt and fixed all errors and recompiled together with a recompiled kernel (3.2.0-35-lowlatency for Ubuntu) with custom DSDT enabled
*Tried compiling 3.7.x series kernel with lowlatency patches
*Tried 20_custom_ehci_hcd script in the /etc/pm/sleep.d/
*Tried a myriad of combinations with suspending modules (stored in /etc/pm/config.d/modules)
*Disabling swap (I know, makes no sense, but at one point I thought the freezes increased when the swap started filling up)
After having to troubleshoot this for over a month, I am sure I am missing a few options here that I simply forgot about.
The end-result is always the same: suspend works flawlessly seemingly random number of times and then in most cases upon resume simply freezes with blank screen (most of the times backlight does not come on, but sometimes does). The wireless hw button works and pressing power button shows momentary write on HD but no peripheral is responsive (keyboard, touchpad, external mouse), nor is the machine accessible via network. Under specific setup (acpi_osi="Windows 2009") machine sometimes freezes while trying to go into suspend after wireless has been disabled and audio muted (hw buttons show different color when those power down). So far, the combination of boot flags that gives me *on average* most suspends before freezing is acpi_osi=Linux acpi=s3_bios pci=nocrs. I also use quiet splash threadirqs (last to boost audio performance).
BIOS options are limited and do not offer settings that some of the proposed fixes suggest. Some of the posts suggest there is a hidden advanced bios but the old suggested way of entering into it does not work.
Other pertinent system info:
8GB dedicated swap partition
No fs encryption
Everything else works perfectly (haven't tried hybernate which is disabled by default on Ubuntu)
12.11 beta11 fglrx driver (fixes "ASIC hang happened" bug)
Using latest manufacturer BIOS (version 17)
Is there any hope for this? Where could the problem lie? Is it the fglrx driver, kernel, or something entirely different?
How could one even begin to troubleshoot this when the system is inaccessible and the syslog not verbose enough to show the problem (or it does not get enabled before the crash happens to log anything useful)? Any assistance with this would be most appreciated! In other words, I don't mind throwing more time on this problem but need help on how to capture relevant information from the kernel that would point me in the right direction as to where the problem lies.
Please let me know if you need any logs/list of devices, etc.
This bugzilla is just used for tracking kernel bugs not for prioritising or arranging any fixing of them. You should contact your distribution or whoever is providing you with support if you want to escalate a bug with them.
Also note that if you are using the fglrx driver then you need to talk to AMD not the kernel upstream.
Thank you very much for the clarification. However, before I start pointing fingers in any particular direction I would like to arrive at something very tangible that points towards the binary driver or some other aspect of the kernel. How can I do this with the suspend? In other words is there a way to capture verbose output from the kernel while it's trying to resume and before the syslog has begun logging things?
Test without ever having loaded the binary driver.