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
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)