Thursday, July 13, 2006

Random tips for TGV travel from Paris

The Train à Grande Vitesse is a comfortable and low-hassle way to travel around the country, and reservations can be made online from the States with no fuss. However, you should know the following two items.

  1. When reserving online for the TGV that departs directly from Charles de Gaulle airport (Paris), the names "Roissy (95)" and "Aeroport CDG 2 TGV (95)" both refer to this station. This was slightly confusing to me; I just made my reservation for Roissy and crossed my fingers. Incidentally the station looks like this:

  2. In order to pick up your ticket at the station, you will need the credit card that you originally used to buy your ticket. You may be tempted by machines that look like this:

    ...which seem great, except for the following minor glitch, if you're a U.S. traveler:

    As most U.S. credit cards are currently magnetic stripe-based, you will have to wait on line at the ticket counter. The ticket counter is slow, so slow that the French guy on line in front of me remarked "Le train, c'est très vite, mais ça? Pffft."

Monday, July 03, 2006

Video corruption on resume from suspend on Thinkpad T42 with Fedora Core 5 and Xorg

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/ now uses the following magic (recent additions in orange):


# Sleep the network
# (Following should all be one line.
# Blogger keeps borking backslash-escaped EOLs)
/usr/bin/dbus-send --system

# 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
/usr/bin/chvt 7

# Wake the network
# (Following should all be one line.
# Blogger keeps borking backslash-escaped EOLs)
/usr/bin/dbus-send --system

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.