Talk:Problems with ACPI suspend-to-ram
After a few resumes with my T43, I get "big green boxes" on my consoles tty1 and tty2. tyy3 to tty6 stays completly black (there should be login prompt). But X still working fine.
This is a minor issue, but anyone with the same problem and a fix/workaround?
--Defiant 13:40, 02 Jun 2006 (CEST)
I have a similar issue on my T60. It seems like the problem is with the framebuffer; that the card is attempting to use the lowest resolution possible when I have the framebuffer set much higher, but that's just my intuition. I'm using hibernate with both EnableVbetool and VbetoolPost set to yes.
An interesting thing is that if I manually call hibernate from an xterm inside X, I get no negative effects. It even fixes the console "big green boxes" if I previously suspended not in X. Also, on resume I see the following messages on the xterm (all previous output is cleared):
Allocated buffer at 0x11010 (base is 0x0) ES: 0x1101 EBX: 0x0000 Calling INT 0x15 (F000: 5E79) EAX is 0x1005F08 Calling INT 0x15 (F000: 5E79) EAX is 0x1005F08 Calling INT 0x15 (F000: 5E79) EAX is 0x5F08 Calling INT 0x15 (F000: 5E79) EAX is 0x5F08 Calling INT 0x15 (F000: 5E79) EAX is 0x45F08 Function not supported
Any ideas?
-- Deason 05:39, 14 July 2006 (CEST)
Just to update/confirm: suspend to RAM only works if I have X running, and I switch to the console running X after resuming. Editing the ACPI sleep script to switch to vt 7 before switching back to the original console seems to work fine, though. It just means that I can't suspend to RAM if I'm not running X. (Putting a check for that in the ACPI sleep script would also be a good idea.) I've tried using EnableVbetool, VbetoolPost, RestoreVCSAData, and RestoreVbeStateFrom from hiberante, but none seem to solve this without switching to X.
-- Deason 21:48, 16 July 2006 (CEST)
Yes it's the vga framebuffer freaking out at you. Try adding acpi_sleep=s3_bios,s3_mode kernel option to /boot/grub/menu.lst
The s3_mode part fixed the green boxes for me. (debian testing, kernel 2.6.16, TP x41)
--Ladoga 06:46, 5 August 2006 (CEST)
Yay, that did it. Also, I'm not sure which option it is, but one of the options in hibernate (either EnableVbetool, VbetoolPost, RestoreVCSAData, or RestoreVbeStateFrom, or all of them) causes the framebuffer to freak out again. Disabling them, and enabling that s3_mode makes it all work again. (Debian Sid, 2.6.17, T60). Putting this in the article, I guess.
--Deason
I had the same problem with the "big green boxes" (except mine were not only green, but many colors :-). I added the acpi_sleep=s3_bios,s3_mode to the kernel boot parameters, and suspend with s2ram -f -a 1 (although I'm not sure that if one uses s2ram, the kernel parameters are relevant?). Anyway, the -a 1 in s2ram made things a little better, but I still had issues with big green boxes once in a while. It was critical, because sometimes, suspend would get stuck right after switching to vt1, and would require a hard power cycle, after which the machine would behave weirdly (X gets really slow, e.g. 45 seconds to bring up a gnome-terminal). I have now tried to add vga=0 (no frame buffer) and use s2ram -f -a 3. Seems to work for now. I will update after more suspend cycles. BTW, the problem with the chvt also happens sometimes, when switching without suspend (just with a crtl-alt 1 or a chvt 1): I get corrupted video with big grey and black boxes on my screen, and everything is dead, i.e. I can't switch out of that state, either using crtl-alt 7 or even killing X (crtl-alt-backspace). I hope this was related to the frame buffer (that;s what pointed me to this post in the first place), and thus hope the vga=0 will do me good. Note that this problem with garbled video when switching to vt 1 also happens with fedora 7 (I'm using ubuntu feisty as my base system), every single time.
--frigaut 4:54, 10 June 2007 (Chilean time)
Contents
Intermittent lock-up on resume with X31
I have an X31 running 2.6.16 (Debian). I'm running Debian patches, with the addition of ieee80211 1.1.14 and ipw2200 1.1.13
Suspend/resume generally works first time, but locks up during resume after a few cycles. Usually the sleep light stays flashing.
A possibly related symptom is that on a few occasions, I've had the wireless connectivity work for a few seconds after resume, and then fail (though this could be fixed by # ifdown eth1; rmmod ipw2200; modprobe ipw2200; ifup eth1).
I've tried the following boot options to no avail: ec_intr=0; nolapic; nolapic noapic
--Malcolm 06:42, 1 September 2006 (CEST)
I've had no more lock-ups since my last post (knock on wood) i.e. about 20 suspend/resume cycles.
Nothing has changed in my config, but I've been manually doing a
# sync
before each suspend, according to the theory that race conditions etc. will be less likely to be tickled if I reduce the interrupt load while ACPI does its work.
Incidentally, it turns out that I was running the equivalent of nolapic all along; dmesg output says:
Local APIC disabled by BIOS -- you can enable it with "lapic"
--Malcolm 10:11, 21 September 2006 (CEST)
Two lock-ups since my last post: after 30 cycles and after 10.
It loooks like this is kernel bug #5555
--Malcolm 00:04, 3 October 2006 (CEST)
Since my last post, I upgraded to Debian stock 2.6.18 kernel. This version includes ACPI 20060707.
I've had one lock-up on resume. Current uptime is 36 days.
--Malcolm 09:17, 6 February 2007 (CET)
Three lock-ups since my last post. Looks like this kernel is no improvement on the others I've tried.
--Malcolm 12:30, 11 February 2007 (CET)
I've been running an Ubuntu 2.6.20.3 kernel for about 3 months, and still experience lock ups. I still suspect the ipw2200 driver is involved, as occasionally it will stop working after a resume. I'll try a 2.6.22 kernel some time.
--Malcolm 11:08, 23 August 2007 (UTC)
I was having the same problem under fedora 7, kernel 2.6.21-1.3194.fc7 - I could resume maybe 3 times out of 4. This is with all combinations of acpi_sleep= and ec_intr=0 boot parameters. Recently I found a suggestion (sorry, I've lost the reference) that the problem could be the kernel cpu speed governor. The suggested cure was (with root permissions) echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor I tried it and have had no lockups for the past week, a few dozen sleep/resumes. I've now edited /etc/sysconfig/cpuspeed to set userspace on boot. Might work for you too - worth a try anyway. --Stephen 17:24, 2 September 2007 (UTC)
My X31 won't wake up from sleep, ever. It beeps as though it's about to, but the fan whirs and the screen stays black and the machine won't respond to anything. Hibernate works fine. This is using ACPI under Ubuntu 8.04.
--Eater 03:10, 6 June 2008 (CEST)
A couple of kernels later, I still have this problem. In 3 months I've had 5 crashes on resume after an average of 24 suspend/resume cycles (range 0 - 55).
I'm now running kernel 2.6.24 (binary from Debian Lenny/Testing). In response to Stephen, I don't have the cpu speed governor in this kernel build, so I guess that's not it.
Relevant kernel bits (from dmesg on resume): ACPI 20070126, e100 3.5.23-k4-NAPI, ieee80211 git-1.1.13, ipw2200 1.2.2kmprq
--Malcolm 02:24, 29 June 2008 (CEST)
I spent 4 months using my machine on a wired connection and experienced a dramatic decrease in the number of lock-ups on resume. This reinforces my belief that the ipw2200 driver is the problem or at least a major contributor. Otherwise things are the same as before, now on kernel 2.6.26 (Debian Lenny), ACPI 20080321, ieee80211 git-1.1.13, ipw2200 1.2.2kmprq --Malcolm 01:57, 11 October 2009 (UTC)
PS This Intel wireless bug may be relevant: http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1854
--Malcolm 02:34, 18 October 2009 (UTC)
With custom kernel 2.6.24.x and some hacks suspend to ram works in 9 of 10 cycles. On suspend i'm using scripts to disable and unload wifi drivers, to eject a possibly attached ultrabay drive and to use the "userspace goveror", as written above - after resume my normal conservative goveror is restored. Before the governor hack it crashed on every second I'm trying to resume, so it's a lot better now. But I don't want to use a system's suspend features, which maybe crashes on resume. So any ideas, why it doesn't work all the time?
I've no idea how to get some debug output or how to reproduce this behaviour, it just happends sometimes in the same setup i'm using all the time.
Symptons: hard-drive is spinning up; sleep light stays on; battery light is going on; systems seems to be under heavy load (fan is rotating after ~10 minutes); display remaining black; no reaction on user input; if connected to my ultrabase, the cd drive is spinning up and it's control light is activated
--Sylence 20:40, 11 August 2008 (CEST)
Unable to resume R40e after suspend-to-RAM
Suspend-To-RAM works fine, but after going to sleep, the laptop (R40e) can't be woken up. It doesn't respond to anything, the battery has to be removed in order to reset it. I tried many different setups, but the problem persists. Any ideas, please?
I have exactly the same problem on a T23. On resume, the laptop won't wake up. The hard disk spins up however. If I power off and attempt to restart the back light comes on, the fan starts spinning but otherwise the computer won't boot. I need to remove the battery to get it to boot up. This might indicate that acpi is interfering with the BIOS some how. I'm currently running the Debian stock 2.6.21-1-686.
--Pault 16:40, 9 July 2007 (UTC)
T60p Docking While Suspended
My T60p exhibits the problem where if I dock it while it's asleep, it shuts off. Has anyone gotten a response from Lenovo about this problem? Is there a fix? I'm getting tired of waking up my laptop before docking it.
--Sridhar 17:50, 2 January 2007 (CET)
Using HDAPS as a module causes a crash on resume with the Linux kernel 2.6.19 (X41)
Does this hapen with the stock hdaps module from the kernel.org sources, or with the one from tp-smapi?
--Zhenech 14:18, 12 January 2007 (CET)
