Note: Narrowly targeted Google-food. Skip if you do not run a recent version of Linux on a Thinkpad T42 with the Xorg X server.
I run Fedora Core 5 on a Thinkpad T42. Like a good conscientious user, I run yum update regularly to download and install the latest security fixes and patches. Sometime in the past month or so, one of these updates broke suspend. Whenever I resume from suspend --- i.e., whenever I close the laptop's lid and open it again --- my desktop's background wallpaper gets corrupted. My lovely shot of Lake Union gets overwritten with noise: either jaggy, staggered horizontal black and white lines, or a sprinkling of randomly colored "off" pixels.
Oddly, this symptom does not manifest itself when I set my desktop background to plain black. However, using a computer without wallpaper is clearly beyond the pale of what a civilized human being can rationally tolerate.
I have no clue what's at fault: the kernel, the X server, or some other part of my laptop's software ecosystem? Who knows? My wild-assed guess is that somewhere during suspend, the video driver or kernel decides that the video memory buffer allocated for the wallpaper bitmap can be safely used for scratch space to doodle upon, or whatever it is that OS software does. I don't want to manually roll back the scads of packages I've updated via yum (Xorg alone installs about two dozen RPMs), and I don't know how to go about debugging this problem for real. I don't even know whose Bugzilla to report this to --- Fedora? Linux kernel? Xorg? Probably all of them will either ask me to debug the problem, or tell me to file the problem on someone else's Bugzilla.
Sigh. Such is the life of the user of a computer system where nobody takes responsibility for the entire hardware/software stack. I like Linux considerably, but at times like this I wonder if I should just ditch it all for a Mac, thereby giving up freedom for convenience.
In any case, my mad Google-fu did not turn up a solution, strictly speaking. However, it did turn up a pointer that eventually led me to vbetool, a system for tickling your video BIOS. My current suspend-and-resume script (/etc/acpi/actions/sleep.sh) now uses the following magic (recent additions in orange):
#!/bin/sh
# Sleep the network
# (Following should all be one line.
# Blogger keeps borking backslash-escaped EOLs)
/usr/bin/dbus-send --system
--dest=org.freedesktop.NetworkManager
--type=method_call
/org/freedesktop/NetworkManager
org.freedesktop.NetworkManager.sleep
# Save vbestate
/usr/bin/chvt 1
/usr/sbin/vbetool vbestate save >/var/tmp/vbestate
/usr/sbin/hwclock --systohc
echo -n mem >/sys/power/state
/usr/sbin/hwclock --hctosys
# Fix video corruption on resume by resetting vbestate.
/usr/bin/chvt 1
if [ -f /var/tmp/vbestate ]; then
cat /var/tmp/vbestate | /usr/sbin/vbetool vbestate restore
rm -f /var/tmp/vbestate
fi
/usr/bin/chvt 7
# Wake the network
# (Following should all be one line.
# Blogger keeps borking backslash-escaped EOLs)
/usr/bin/dbus-send --system
--dest=org.freedesktop.NetworkManager
--type=method_call
/org/freedesktop/NetworkManager
org.freedesktop.NetworkManager.wake
Note the chvt and vbetool vbestate calls, which save the state to /var/tmp/vbestate before suspend and restore it after suspend. You're not supposed to save and restore the Video BIOS state while you're in an X session, so I use chvt to switch to a text console before invoking vbetool, and back to the X console afterwards. This appears to fix the video corruption problem. Truthfully, I don't know why. Oh well. In the absence of understanding, I'll settle for voodoo.
For reference, I am currently running:
- kernel-2.6.16-1.2133_FC5
- xorg-x11-server-Xorg-1.0.1-9.fc5.5
UPDATE 26 August 2006: Fixed sleep/wake of network.
