Bug 220977 - Thinkpad T43 fails to resume after suspend
Thinkpad T43 fails to resume after suspend
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2006-12-29 16:11 EST by jonathan baron
Modified: 2008-01-07 21:52 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-07 21:52:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description jonathan baron 2006-12-29 16:11:27 EST
Description of problem:

Starting with kernel-2.6.18-1.2849.fc6, resume after suspend no longer works on
my Thinkpad T43.  Various symptoms depending on how I try to do it.  For a while
it was working with kernel-2.6.18-1.2868.fc6, with acpid running and with a
sleep.sh in /etc/acpi/actions that both saved and restored vbestate(?). I had to
open the lid twice to get it to restore, but now for some reason that just leads
to a crash.

How reproducible:

Very reproducible, but, as I say, with different symptoms depending on what
workaround I try.  The initial symptom was that the screen would be blank, and
that is why I tried the vberestore, but now that seems to have stopped working too.

What bothers me is that I have seen no other reports of this.  Perhaps it isn't
really a bug.  But suspend/resume works fine for me with earlier kernels.  I
should note that I am using xorg-x11-drv-fglrx.

This is very similar to bug 16201, and I would have added a comment to that one
except that it said not to.
Comment 1 jonathan baron 2007-01-28 18:49:09 EST
With kernel-2.6.19-1.2895.fc6, suspend/resume seems to work.  It did not work
the first few times I tried.  But then I did two things, and I'm not sure
whether both are necessary.  First, I added
to the end of the "kernel ..." line in /etc/grub.conf.
That by itself did not solve the problem.

Second, I put the following script (from an older effort I made to get things to
work) in /etc/acpi/actions/
calling it sleep.sh:


# remove USB 1.1 driver
rmmod uhci_hcd
# sync filesystem and clock
/sbin/hwclock --systohc

# switch to console
chvt 6
/usr/sbin/radeontool light off

vbetool vbestate save > /tmp/vbestate

# go to sleep
echo -n "mem" > /sys/power/state

vbetool vbestate restore < /tmp/vbestate
rm /tmp/vbestate

# readjust the clock (it might be off a bit after suspend)
/sbin/hwclock --adjust
/sbin/hwclock --hctosys

# reload USB 1.1 driver
modprobe uhci_hcd

# turn on the backlight and switch back to X
radeontool light on
Comment 2 jonathan baron 2007-02-02 10:32:00 EST
It stopped working again.  I have not changed the kernel, but there was a new
version of xorg-x11-server-Xorg.i386 1.1.1-47.5.fc6, and this may be the
problem.  As of now, it suspends, and recovers to the point where I can see the
yellow letters "inu" (part of Linux, I assume) in the upper left.  But the
wireless doesn't work yet.  So I have to reboot manually.
Comment 3 jonathan baron 2007-02-04 09:18:43 EST
If I turn on acpid (with chkconfig, so that it is on when the computer boots),
then things almost work.  One problem is that, when I open the lid, the computer
wakes up (almost) but then goes right back to sleep.  (I had this problem before
and solved it by turning off acpid.)  The second time it wakes up, but without
Xorg.  If I then type ctrl-alt-F1, I get a prompt to log in.  I log in as root
and say "killall Xorg" and then X comes back.

If I could jump to conclusions here, it seems that what has stopped working is
hal.  The problem of going back to sleep is the result of conflict between hal
and acpi.  But then I really am talking through my (red?) hat.
Comment 4 jonathan baron 2007-02-25 05:05:36 EST
Suspend/resume works now, after installing xorg-x11-drv-fglrx-8.34.8-3.lvn6 and
kmod-fglrx-8.34.8-  In /etc/acpi/actions, I have

# remove USB 1.1 drivers - not sure all these are needed
rmmod uhci_hcd
rmmod ohci_hcd
rmmod ehci_hcd

# sync filesystem and clock
/sbin/hwclock --systohc

# switch to console
chvt 6
/usr/sbin/radeontool light off

# go to sleep
echo -n "mem" > /sys/power/state

# readjust the clock (it might be off a bit after suspend)
/sbin/hwclock --adjust
/sbin/hwclock --hctosys

# reload USB 1.1 driver
modprobe ehci_hcd
modprobe ohci_hcd
modprobe uhci_hcd

# turn on the backlight and switch back to X
radeontool light on
Comment 5 Jon Stanley 2008-01-07 20:54:07 EST
(This is a mass-update to all current FC6 kernel bugs in NEW state)


I'm reviewing this bug list as part of the kernel bug triage project, an attempt
to isolate current bugs in the Fedora kernel.


I am CC'ing myself to this bug, however this version of Fedora is no longer

Please attempt to reproduce this bug with a current version of Fedora (presently
Fedora 8). If the bug no longer exists, please close the bug or I'll do so in a
few days if there is no further information lodged.

Thanks for using Fedora!
Comment 6 jonathan baron 2008-01-07 21:18:18 EST
It is nice to see that someone finally read this other than me!

This bug has gone away, come back, gone away, come back, ... through several
cycles.  Now I'm using Fedora 8, and with the latest drivers and kmod-fglrx from
livna, the bug is back:
Thus, I have dropped back to the previous version.  But I suspect that this is
not the place to report bugs.
Comment 7 Jon Stanley 2008-01-07 21:31:04 EST
No, I didn't read the bug - I just did a mass update :) However, you have my
attention now :)

I'm going to change the version in this bug to F8, since it occurs there.  Also,
could you please try any applicable workarounds found at
http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-index.html ?
Comment 8 jonathan baron 2008-01-07 21:42:07 EST
The same bug is on my desktop computer (which has a similar ATI video card and
uses the same driver), and I tried these things there and they didn't work.

I think the problem is with the driver or the kmod-fglrx.  I suspect it will be
fixed with the next version.  They seem to come out every month.  This is a
proprietary driver, still, so there isn't much we can do but wait.  If you
really think that further testing on my laptop will do any good, I'll do it, but
I'm reluctant.
Comment 9 Jon Stanley 2008-01-07 21:52:04 EST
I really don't think so - I was hoping that one of the quirks would help.  Since
it's a proprietary driver, I'm going to close this CANTFIX.  Feel free to
re-open the bug if it's found not to be the driver.

Note You need to log in before you can comment on or make changes to this bug.