Skip to content

Suspend not as suspenseful as once thought

Shock! A blog post that doesn’t have anything to do with SD cards. :-)

My personal life has been rather hectic over the last few weeks so I’ve had precious litte time to do any real hacking, but I did manage to find time yesterday to get Linux up and running on my new work laptop. It’s a Macbook Pro, and the first piece of Apple hardware that I’ve ever had in my possession (I’m pleased to say I’ve managed to never buy any Apple hardware). It’s one of the new 15″ Santa Rosa models and it’s not too bad. Later, I think I’ll write a more detailed description of what it took to get going, but right now I just want to make an observation about Suspend/Resume.

And that observation is that we’ve really come a long way. I was able to do a raw suspend (echo ‘mem’ > /sys/power/state) and resume and it actually came back to life. There are admittedly some niggles with the graphics (nvidia binary driver) which means you need to vt switch away from X and back after resuming to get your picture, but I was amazed to see the wireless and USB come right back.

And it gets even more amazing. With suspend/resume happiness fresh in my mind, I decided to be brave and see what my desktop machine could do. It’s a Athlon X2 based machine with nvidia chipset and graphics and an Audigy2 sound card. Traditionally, suspend/resume has had a worst record on the desktop because you’re more likely to encounter a driver that can’t cope but I figured I’d give it a go – the most important requirement was that the HD controller driver (sata_nv) was suspend aware and this support went in around 2.6.20 – nobody wants to corrupt their disks when trying to suspend (I’ve been there before).

Like most desktop’s, my one’s BIOS offers a choice between S1 and S3 suspend, and I tried both of them out – and surprise, surprise, they both worked! Everything came back like I left it.

I also took the opportunity to use my friendly Kill-A-Watt to see what the power consumption was like, and I made some interesting observations. My desktop seems to idle around 120W which can rise to around 170W under non-graphics load (I don’t know what a 3D load would do, but I could see it pushing up to around 250W). In S1, it drops to 85W and in S3 to 10W. Amusingly, it still pulls 7W when ‘off’. That seems like a hell of a lot just to support Wake-On-LAN!

But the moral of the story is that a modern system with a modern kernel seems to have a pretty good chance of Just Working(tm) when it comes to suspend and resume.

{ 4 } Comments

  1. Anon | 5th August 2007 at 13:32 | Permalink

    NVIDIA binary driver and Santa Rosa Ubuntu bug.

  2. Philip Langdale | 5th August 2007 at 13:42 | Permalink

    Unfortunately, your link isn’t. :-)

    But here’s a useful link regarding the crazy colours bug (including a work around). I’ll talk about this more when I discuss setting up the mbp.

  3. Sergey | 14th August 2007 at 14:53 | Permalink

    Do you use compiz? I have troubles with it and suspend. Also the vt switching trick only works the first time for me. Do you have a stable suspend/resume experience over a time?

  4. Philip Langdale | 14th August 2007 at 15:40 | Permalink

    Not regularly but I play with it from time to time. My past experience with nvidia cards is that they do not handle suspend/resume in 3d mode well. Right now I use xfwm4 with the 2D compositor and it’s fine.

    I just checked and I could do 2 back to back suspend/resume cycles and the VT switch workaround brought my display back both times.

    Of course, there *is* the bug where the nvidia chip comes back in a very slow mode – slow enough that 2D is almost unusable. This seems to only affect G80 (my desktop has a G70 and it seems fine when I resume) and it means you pretty much need to restart X anyway. Hopefully that will be fixed in the next driver release – it’s a known problem.

Post a Comment

Your email is never published nor shared. Required fields are marked *