Thursday, 1 January 2009

Happy New Year, and it's looking good so far .... suspend and resume ARE working on the T60p, really :-)

Following on from previous posts here and here and here, I was still struggling to get suspend and resume to work reliably on the Thinkpad T60p with Intrepid.

Given that this used to work when I first installed Intrepid in early November, I'm assuming that a recent update has broken something e.g. a new kernel or an updated fglrx driver.

I experimented with various drivers including the supported open-source fglrx driver that comes with Intrepid, the radeon / radeonhd drivers, as well as the most recent fglrx driver from the ATI site here.

Sadly nothing seemed to work and I was becoming resigned to having to shut down and boot up each time I went from home to Starbucks to the office to home to Starbucks ....

Symptom-wise, I could suspend without problems, but would find that the display remained dark on resume. Whilst the PC seemed to be working e.g. [CapsLk] light could be toggled on/off, hard disk appeared to spin when I hit various keys etc. I couldn't get the display to return, and ended up using the power button - which is a less than ideal way of shutting down.

After lots of trial and lots of error ( and lots of Google ), I worked out that: -

(a) the problem related to virtual terminals
(b) that the combination of compiz and fglrx was definitely the root cause ( apart from the aforementioned updates )

I went down a few blind alleys, including playing with /etc/default/acpi-support, removing the chvt command from the resume scripts and using vbetool to toggle the display on.

Happily, after a couple of days of seriously hard work ( thank goodness for coffee ), I managed to find the solution or, to be more honest and accurate, I managed to find the solution that Dave Abrahams had posted here.

Before I post the solution, let me outline my environment: -

Hardware 2007-AE7 IBM Thinkpad T60p
OS Ubuntu Linux 8.10 ( Intrepid Ibex )
Kernel 2.6.27-9-generic
Graphics ATI MOBILITY FireGL V5200
OpenGL 2.1.8087 FireGL Release
Driver fglrx 8.54.3 [Oct 10 2008]
xorg-driver-fglrx ( 8.543-0ubuntu4 )
Compiz compiz-core 0.7.8-0ubuntu4.1
Fusion compiz-fusion-plugins-main 0.7.8-0ubuntu2.2
Suspend Mode pm-suspend

If it helps, here is my /etc/X11/xorg.conf as well as the listing produced by the sudo lspci -vv command here.

I've validated this solution on three separate Ubuntu environments, including my production build from November 2008, as well as two clean builds over the past two days.

As far as I can understand, the problem is that, during the suspend process, compiz fails to shut down normally and "locks" the virtual terminal on which X runs ( typically this is VT7 ). This does appear to be a BUG #197209 in Ubuntu that, I assume, has been recently introduced in a kernel or module update.

The "solution" or, to more precise, circumvention is use a script ( 00compiz-fglrx ) to kill compiz during the suspend process, and restart it on resume.

A second script ( 50compiz-fglrx-noclear ) is used to stop the Change Foreground Virtual Terminal ( chvt ) command from running until compiz is killed ( to be more specific, it "blacklists" the default /usr/lib/pm-utils/sleep.d/00clear script from running on resume, thus preventing the chvt command from being run ).

Dave wrote these two scripts: -

/etc/pm/sleep.d/00compiz-fglrx

and: -

/etc/pm/config.d/50compiz-fglrx-noclear

These can be downloaded to, say, your home directory and then deployed as follows: -

sudo cp ~/00compiz-fglrx /etc/pm/sleep.d
chmod +x /etc/pm/sleep.d/00compiz-fglrx
sudo cp ~/50compiz-fglrx-noclear /etc/pm/config.d
chmod +x /etc/pm/config.d/50compiz-fglrx-noclear


Once deployed, check the file locations, execution bits and permissions as follows: -

ls -al /etc/pm/sleep.d/00compiz-fglrx

should return: -

-rwxr-xr-x 1 root root 6746 2009-01-01 17:53 /etc/pm/sleep.d/00compiz-fglrx

and: -

ls -al /etc/pm/config.d/50compiz-fglrx-noclear

should return: -

-rwxr-xr-x 1 root root 182 2009-01-01 17:52 /etc/pm/config.d/50compiz-fglrx-noclear

Once you've rebooted, you should be able to suspend and resume without problems.

If needed, you can enable logging on the /etc/pm/sleep.d/00compiz-fglrx script by setting a value to the parameter LOG_FILE_NAME e.g. LOG_FILE_NAME='~/suspend.log'.

This newly-created logfile, along with /var/log/pm-suspend.log should help determine the cause of the problem.

Happy Holidays 8-)

7 comments:

David Abrahams said...

I'm now maintaining the scripts in this repository at github. Any further fglrx-related improvements I come up with will show up there.

Dave Hay said...

Hi David, excellent, many thanks for this

todd. said...

Thanks for this, guys.

I notice that one of you mentioned on the Ubuntu bug page that this is probably a hardware issue, because suspend works on some Dell. Just to add a piece of information: these scripts fixed a similar problem for me, on a T60 (note the absence of a p), which I believe has different graphics hardware.

I'm not certain this is germane, but I thought I'd toss it out there.

Thanks again!

Unknown said...

Thanks for posting this, I've been having issues with suspend/resume for a couple of months now with my gateway m6862 (ati mobility something or other video card). Suspend now works perfectly, thanks so much!

Unknown said...

Dave - FYI, I'm running Ubuntu Ibex on a Thinkpad T43p (Radeon mobility v3200). I experienced same kind of resume hangs running fglrx. David Abrahams' scripts fixed my system too - yay!

Anonymous said...

Thanks Dave - just tried this on my Thinkpad W500 with Ubuntu 8.10 and it's worked perfectly. No changes to your scripts or anything - I just downloaded them and ran the commands you suggested, rebooted and now it's all working.

Many thanks - you've saved me a lot of time.

mitch said...

Awesome. I've downgraded from 10.04 to 8.10 to get fglrx working, since radeon in Lucid was crashing randomly for me. The lack of suspend was painful, until I found this tip. I just disabled compiz via Appearance settings, and voila, suspend works :-)

Note to self - use kubectl to query images in a pod or deployment

In both cases, we use JSON ... For a deployment, we can do this: - kubectl get deployment foobar --namespace snafu --output jsonpath="{...