Title photo
frugal technology, simple living and guerrilla large-appliance repair
Tue, 08 Feb 2011

Suspend/resume in Debian Squeeze with the stock 2.6.32 and 2.6.37 Liquorix kernels on the Lenovo G555

Suspend/resume. Or in words that non-geeks can understand, sleeping/waking up. It’s one of those things that not just Linux but also BSD and even Windows have been trying to get right for years.

It’s all about standards and drivers, which tend to be non-standard and poorly functioning in a given software environment.

I’ve never had a machine that I’ve used for my day-to-day computing that suspended and resumed properly in Linux. The Lenovo G555 (purchased early 2010) seems to do well with suspend/resume in Windows 7.

And our aging iBook G4 (2003-ish) does suspend/resume like a champ. That’s how it is with Apple’s OS X and their tight control over the hardware on which their software runs. That’s the holy grail for me; suspend/resume is fast, it always works, the network is back up within a couple of seconds.

Even OpenBSD is working on suspend/resume via the ACPI system in most computers these days. I have yet to try OpenBSD 4.8, in which this feature has received a whole lot of work.

But Linux? I haven’t had a whole lot of luck. Not with my Gateway Solo 1450 (now the 7-year-old’s laptop), the Toshiba 1100-S101, or the Lenovo G555. One reason I bought the Lenovo (the main reason being a nexus of “cheap” and “Lenovo”) was that I hoped it would benefit from the connection to Thinkpads of yore, which are traditionally well-supported by free, open-source operating systems.

Well, that hasn’t exactly worked out. My tests of Ubuntu 10.04 with the fglrx/Catalyst proprietary driver were all positive. I didn’t run Ubuntu long. Based on my limited test at the time, Ubuntu would have been a good way to go.

Alas I decided on Fedora 13, and suspend/resume did function on the Lenovo G555, albeit briefly.

Now I’m running Debian Squeeze, as I have for about two months at this point. My suspend/resume tests have been inconclusive to poor until now. A lot depends on the kernel, and Squeeze ships with 2.6.32. Now that I’m running 2.6.37 from Liquorix.net, which gets updated fairly often, by the way, my hardware is performing better all around.

This morning I manually suspended the Lenovo twice, and it resumed fine on both occasions. I’m not sure if the screensaver complicates the whole process (i.e. when it is engaged), and that’s something I will be checking. Being able to automatically suspend the computer via GNOME’s Power Management settings would be huge.

So here’s where I stand: In Debian Squeeze with the 2.6.37-0.dmz.7-liquorix-amd64 #1 ZEN SMP PREEMPT kernel, suspend/resume works when manually invoked by the user. I should also mention that I installed firmware-linux-nonfree, which I believe is helping me use kernel mode setting with my ATI Mobility Radeon 4200 HD video chip. I’ll have to try this with and without that package.

Later that day … I used the GNOME configuration to go to screensaver in 3 minutes, turn the screen backlight off in 5 minutes and then suspend in 10 minutes. I then left the system in suspend for an addtional 10 minutes, then resumed (which I do with the Lenovo by tapping the space bar, by the way).

It all worked.

I will keep testing, but I’m very encouraged with what I’ve learned so far.

The following day: I ran the Lenovo all day, doing production for the web site (that would be http://dailynews.com), which entails using two browsers (Iceweasel/Firefox and Chromium), the Geany text editor, the gThumb image editor, Filezilla FTP client, Thunderbird mail client, Empathy IM client, plus more than a little Rhythmbox, and a few terminal windows.

I run standard GNOME as it ships in Squeeze. I upped the number of workspaces from four to six, and I’m thinking of adding a few more than that.

All of this grabs a lot of memory, and the Linux kernel even saw fit to grab a few megabytes of swap.

At the end of my day, I suspended the laptop by pressing the power button and selecting suspend from the menu.

I packed the entire thing up, then came home, had dinner, did various and sundry other things, then pulled the laptop out of the bag ( Target special, if you must know; originally purchased for my freebie, now dying Toshiba 1100-S101).

I hit the space bar.

The screen flashed, the screen-lock dialog came up. I typed in my password, and I was back on my still-working desktop.

I wouldn’t be making such a big deal out of this if I had ever gotten suspend/resume to work in Linux with any other machine I’ve used in the four-plus years I’ve been running Linux distributions and BSD OSes.

Never.

I’ve read dozens of other commenters on blogs far and wide say, “suspend has always worked for me; and so should it for you.” I’ve never been in that crowd.

There have been times when I’ve had suspend/resume work briefly, in between software updates (and hence for maybe a week at a time).

I’m cautiously hopeful that working suspend/resume will continue, and not just in Debian Squeeze but possibly in other distributions as well.

Next I’ll be testing the “stock” Squeeze 2.6.32 kernel, even though I’ll pretty much be sticking with newer kernels due to my sound-muting issues. I’ll also be looking into newer kernels in Debian Backports once they’re in place for Squeeze.

A key test will be the 2.6.38 kernel, which will carry the heralded 200-line patch that’s supposed to make everything in Linux faster and better. If sound and now suspend/resume hold up in Debian Squeeze once either Liquorix or Backports delivers that kernel, it’ll be nothing short of amazing.

And the next day: I did a suspend/resume test with the stock Debian 2.6.32 kernel, whose uname outputs the following: 2.6.32-5-amd64 #1 SMP Wed Jan 12 03:40:32 UTC 2011 x86_64 GNU/Linux

Suspend/resume worked.

While I’m unsure of the exact package that is allowing suspend/resume to function, I suspect that firmware-linux-nonfree does have something to do with it. For all the trouble I’ve had with kernel mode setting both in ATI and Intel video environments, running the open ati/radeon driver with KMS working properly seems to be a “win” for things like suspend/resume. My exact grasp as to what’s happening is that the firmware is allowing the video system to use the drm module, about which I was getting warnings in my dmesg (that it wasn’t loading) until I installed the firmware package.

I’ll have to try to pull firmware-linux-nonfree and see how everything works.

What I do know is that running the fglrx/Catalyst proprietary driver for ATI graphics was a less-than-pleasant experience in Fedora 13/14. When I was able to run the open-source driver, everything ran fast and looked great. Things slowed down considerably with fglrx, and while they sped up when I was able to tweak it a bit (mostly making sure the kernel and the video driver were somehow in sync; don’t ask because I barely know what happened), I quickly realized that bringing in software not just from a third party, but closed binary software from a third party that isn’t properly managed via the built-in package-management utilities (dpkg/apt/Aptitude in Debian, rpm/Yum in Fedora) doesn’t strengthen the system as a whole in any way.

During that Fedora experience, it would have all gone better if that project’s unofficial-official third-party repository RPM Fusion had kept up with the closed fglrx/Catalyst drivers the way it did/does with closed drivers for nvidia graphics (it did not, prompting me to wrangle with the beast that is AMD/ATI’s bolt-on Catalyst installer).

If you do want to explore running the fglrx driver, Debian has a page on the wiki that can help you.

Comments from the original Flatpress post:

Pierre Thursday, February 10, 2011 - 05:38:13

As you said, suspend/resume depends a lot on the hardware. I use to have a Lenovo t60p and suspend/restore always worked with ubuntu (from 8.04 to 10.04) but now I own a Lenovo t500 and suspend/resume doesn’t work (again, with ubuntu, 10.10 this time). I also own a very old ibook G3 clamshell that I use as a jukebox and a X terminal, with Debian Lenny, suspend/resume works well. An old Fujitsu B series, no suspend, etc.

steven Thursday, February 10, 2011 - 18:30:11

I’ve had people suggest to me that since machines boot so fast, why suspend — why not just power down? I pretty much do that. But when a feature is available, you want to at least have the option of using it, right? Suspend/resume has been so good on our Apple iBook, I wanted it to work in Linux. And now it does. I remember feeling this good about Debian Lenny when I had everything set up. I’m glad to be there with Squeeze. I’m better equipped (both hardware- and knowledge-wise) to do more with Squeeze than I did with Lenny, and I’m very encouraged that we all have two years ahead of us in terms of security support for the release.

seg Wednesday, April 20, 2011 - 22:20:34

Interesting! I had suspend working fine on LMDE 2010 but upgraded to 2011 and lost it. Plain vanilla Squeeze had the same problem as did SalineOS…all the same 6.0 platform. With SalineOS, I upgraded to testing and added the latest liquorix kernel (2.6.37-5) using smxi and Voila! Suspend now works! I don’t have any “firmware” listing in my sources.list. I think it is the kernel and it is fixed in the liquorix versions. My hardware is a desktop with a gigabyte AM2+ mobo. Just leaving it turned on isn’t a good approach at this location with the highest $/kwh of the US (about $.45) which is why I care with a desktop.

steven Thursday, April 21, 2011 - 00:09:00

Liquorix kernels can really help - they’re optimized for the desktop, and you’re not stuck with 2.6.32. All my problems were solved with Liquorix’s 2.6.37 - suspend/resume and audio are perfect.