Red Hat Bugzilla – Bug 254214
Suspend to RAM fails on Thinkpad T61
Last modified: 2009-01-09 02:13:29 EST
Description of problem:
pm-suspend starts the suspend process and the suspend light comes on
momentarily, but the machine resumes by itself after a few seconds.
Version-Release number of selected component (if applicable):
kernel-188.8.131.52-65.fc7 and all previous F7 kernels
Steps to Reproduce:
1. Click suspend from the GNOME power manager or run pm-suspend from console
2. Sit back and watch
Machine suspends for a few seconds, then resumes by itself.
Machine should suspend until resumed by the user pressing the power button or
Excerpt from /var/log/messages attached.
Created attachment 172451 [details]
Excerpt from /var/log/messages spanning suspend/resume.
Moving to F8Test2 and bumping severity. (It would be nice to have it fixed in
F7, but I've moved that machine to F8T2 and I'd rather see it fixed there at
this point.) It's important to have suspend working on a laptop.
Notes: The machine has NVidia Quadro NV140M graphics. I'm currently using the
Xorg VESA driver, as the nv driver doesn't work. But in F7, the suspend problem
occurred with the NVIDIA proprietary driver as well.
I needed this quirks on my T61 (intel graphic):
pm-suspend --quirk-s3-bios --quirk-s3-mode --quirk-vga-mode3
You can check this site for more info:
That solves the problem of the vesa driver coming back blacked out, but it does
not solve the problem where the machine refuses to stay suspended.
So the machine suspends, resumes immediately with no operator action, and if I
use the quirks, the screen restores.
I have another data point:
I installed RHEL5 Desktop on an identical machine. The vesa driver doesn't work
at all, nor does the nv driver. But with the nvidia proprietary driver (as
packaged by ATRPMs), that machine does suspend and stay suspended.
Unfortunately, it freezes on resume, but I suspect that's a quirk issue.
I see. So what about disconnecting external stuff (network) - maybe it is a
WakeOnLan stuff which wakes your system (happened to me).
Don't think so. Wake-on-LAN is off in the BIOS. There is no wired connection.
No other external devices connected. I tried powering off the wireless before
suspending and that didn't help.
Also, even with the above quirks settings, the Nvidia proprietary driver
self-restores and the display comes back black.
I've been told (but have not yet looked) that there is a patch in Ubuntu's acpi
subsystem that resolves this issue.
The latest updates to RHEL5 include a VESA driver that works. With the quirks
listed in comment #4, an identical machine to mine but running fully updated
RHEL5 suspends, stays suspended, and resumes perfectly.
I used the kernel-184.108.40.206-85.fc8 SRPM to build a vanilla kernel, booted that in
runlevel 3, and enterend pm-suspend from a virtual console. The machine
suspended, resumed immediately by itself and left the screen black (no
backlight), though the keyboard was still responsive.
(In reply to comment #8)
> enterend pm-suspend from a virtual console. The machine
> suspended, resumed immediately by itself and left the screen black (no
> backlight), though the keyboard was still responsive.
AFAIK pm-suspend do not uses any quirks if not specified in command line:
If you issue a pm-suspend command without any options then
the fdi quirks will not be used. You still have to use the
--quirk-dpms-on type arguments. There is discussion to add
a new argument --auto to use the hal quirks, but this has
not yet been included upstream.
You can try to check /usr/share/hal/fdi/information/10freedesktop/20-video-
quirk-pm-* if you want to know what quirks are there for your HW and use pm-
suspend with them.
Created attachment 290815 [details]
lshal | grep system.hardware
I have the same problem with the 14", Intel-graphics variant of Thinkpad T61.
It just resumes immediately after suspending, though in my case the graphics
came back up.
My model is listed in the HAL quirks file. I tried adding
acpi_sleep=s3_bios,s3_mode to GRUB as well (is it actually needed?) and the
same thing happens. Hibernating also bounces back immediately, but worse --
keyboard input is ignored afterwards.
My T61 with Intel graphics suspends/resumes correctly with updated F8
According to your lshal output your T61 type is not listed in /usr/share/hal/
fdi/information/10freedesktop/20-video-quirk-pm-lenovo.fdi, so we need to add
it there upstream. Could you please test these commands if they suspends your
pm-suspend --quirk-s3-bios --quirk-vbemode-restore
> I tried adding acpi_sleep=s3_bios,s3_mode
> to GRUB as well (is it actually needed?)
I do not think so (did not saw it in any howto)
(In reply to comment #9)
> (In reply to comment #8)
> > enterend pm-suspend from a virtual console. The machine
> > suspended, resumed immediately by itself and left the screen black (no
> > backlight), though the keyboard was still responsive.
> AFAIK pm-suspend do not uses any quirks if not specified in command line:
> If you issue a pm-suspend command without any options then
> the fdi quirks will not be used. You still have to use the
> --quirk-dpms-on type arguments. There is discussion to add
> a new argument --auto to use the hal quirks, but this has
> not yet been included upstream.
> -- http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html
> You can try to check /usr/share/hal/fdi/information/10freedesktop/20-video-
> quirk-pm-* if you want to know what quirks are there for your HW and use pm-
> suspend with them.
Tried with various combinations of quirks on the command line, but I think the
important lesson is that, quirks or no quirks, using the vanilla kernel does not
affect the symptom of instant resumes.
The RHEL5 kernel and vesa driver work most of the time (in particular, after a
fresh boot), but fail intermittently to stay suspended as well.
Bug #404621 looks like it might be relevant.
I see, you used spec file from kernel-220.127.116.11-85.fc8 SRPM to build a vanilla
kernel. I have no experiences with this.
Based on the discussion at
inspecting the kernel.spec file, I did this by running
rpmbuild -bb --with vanilla kernel.spec
That appears to skip all but one patch to the vanilla kernel, as noted in the
comments. (Also modified the spec file to add a local suffix to the RPM version
Shouldn't this quirk listing already match my hardware?
system.hardware.product = '7658CTO' (string)
(7658 is a prefix of 7658CTO)
Calling pm-suspend manually still causes the bounce:
s3-mode only: backlight is off on resume, had to switch to virtual console and
back. the virtual console memory is also corrupted until I log in and clear the
s3-bios and vbemode-restore: bounces, everything ok on resume
you are right, that should match your hardware. Thing is, that pm-suspend do
not read guirks from *.fdi files (see citation in comment #9), so quirks have
to be specified manually on the command line. The only (am I right?) tool which
loads the quirks from *.fdi files is a GNOME Power Manager (http://
According to 20-video-quirk-pm-lenovo.fdi, you should be able to correctly
pm-suspend --quirk-s3-bios --quirk-s3-mode
I haven't found *any* combination of quirks for which the machine stays
suspended. Quirks affect whether the display comes back when the machine cycles
out of suspend mode, or whether the machine freezes on resume from suspend or
hibernate, but nothing I tried keeps the machine asleep when suspending.
In particular, the above doesn't cause the machine to stay asleep. It does
bring back the (vesa) display after the machine cycles awake by itself.
BTW, mine is a 7663CU3. The only quirk active by default in
20-video-quirk-pm-lenovo.fdi is s3_mode. But pm-suspend --quirk-s3-mode comes
back (by itself) with the backlight off. I must reboot to get the display lit
Seconding Matthew here. I've tried pm-suspend manually, with both s3-bios and
s3-mode alone: bounces, backlight off. Matthew, if you switch to a vt and back
to X, does it turn the backlight back on? That fixed it here
s3-bios alone: bounces
s3-bios and s3-mode: bounces
I wonder if this is common among Santa Rosa-based laptops or is a specific
Lenovo problem. Apparently the new Dell Latitudes (830, perhaps 630 also) do not
OK In response to Bug #249367, xorg-x11-drv-nv-2.1.6-1.fc8.x86_64 is now in F8
updates-testing. That driver works (at least partially) with the NVS-140M. So
the following comments apply to that driver.
The bounce out of suspend still occurs. The display comes back blank (backlight
off). Switching to a VC does not turn the backlight on. (In response to
Michael's question in Comment #19, switching to a VC did not turn the backlight
on in that case either.) The caps-lock key does not toggle the LED (this is
what made me think that the machine was frozen in comments above, but it may not
have been), but the keyboard still functions otherwise, and I can reboot with
No combination of quirks that I have tried so far brings the display (or
caps-lock LED) back after the bounce. I tried:
- no quirks
- s3-mode and s3-bios
- s3-mode, s3-bios, and vbemode-restore
It's really frustrating how several variants of the T61 behave differently. The
caps-lock key should behave identically in your case as in mine as it is not
videocard-specific, but it does not...
The bouncing issue is common to both 14"/Intel and 15"/nVidia, but in the former
case, everything else works, and in the latter case, you have the capslock issue
and the backlight problem. And using the VESA driver, or suspending from
runlevel 3, does not change things?
Mine's a 14"/nVidia.
With the vesa driver, suspend bounces, but the screen restores correctly with
s3-bios and s3-mode quirks (see above). The only other issue I have with the
vesa driver is Bug #351661 (and FWIW, that is not an issue with the new nv
driver). I also haven't gotten the nVidia proprietary driver to restore the
display after the bounce.
Per mailing list discussion:
it seems that the problem is resolved:
Is this something that we can automate on installation?
Note that there is still a problem, that if any sound is playing when the laptop
is suspended, sound playback does not work on resume (might be a pulseaudio
problem, will investigate further).
Bizarre thing is, in F9 suspending from GNOME does not work (but suspending with
pm-suspend manually works)
That was my e-mail, and I had intended to post here shortly after I sent it, but
hadn't had time.
I wonder if there isn't some other bug involving those drivers. The person who
told me about this workaround said that there's some auto-restart feature to the
devices that's interfering with suspend, but maybe the drivers themselves should
deal with that?
In F9, suspending in GNOME bounces? Or some other graphics issue?
Sorry, also meant to mention that the nVidia proprietary driver does return
after resuming from suspend to RAM, but the machine locks up after resuming from
(In reply to comment #23)
> Note that there is still a problem, that if any sound is playing when the
> is suspended, sound playback does not work on resume (might be a pulseaudio
> problem, will investigate further).
I have the same problem on my T61. Unloading the snd_hda_intel module seems
to avoid it. So now I have SUSPEND_MODULES="snd_hda_intel ehci_hcd uhci_hcd".
Is this something that can be automated as a hardware-specific HAL quirk?
F9 works just like F8. The GNOME issue was a red-herring, having to do with
ConsoleKit and SELinux. I'm temporarily running with SELinux in permissive mode
to ignore those oddities.
The Intel HDA sound issue is weird. On my machine at least, I don't need to add
it to SUSPEND_MODULES
Still broken out of the box in F-9 on my T61, non-proprietary driver.
SUSPEND_MODULES="ehci_hcd" fixes the immediate-resume-after-suspend problem on F9 on my T61 with Intel graphics and wireless.
Thaks for that; I have been unloading ohci_hcd as well, unnecessarily(In reply to comment #29)
> SUSPEND_MODULES="ehci_hcd" fixes the immediate-resume-after-suspend problem on
> F9 on my T61 with Intel graphics and wireless.
Thanks for that; I have been unloading ohci_hcd as well, unnecessarily
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '8'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 8's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 8 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Suspend-to-RAM seems to be working just fine with Fedora 10 on a ThinkPad T61, provided you initiate it by running pm-suspend or by selecting Suspend from the gnome-power-manager applet menu (pressing Fn-F4 initiates the suspend operation but it always resumes immediately).
The suspend-bounce problem appears to be solved in F10.
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.