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)