Bug 254214 - Suspend to RAM fails on Thinkpad T61
Summary: Suspend to RAM fails on Thinkpad T61
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 8
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-08-24 19:48 UTC by Matthew Saltzman
Modified: 2009-01-09 07:13 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-01-09 07:13:29 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Excerpt from /var/log/messages spanning suspend/resume. (7.96 KB, text/plain)
2007-08-24 19:48 UTC, Matthew Saltzman
no flags Details
lshal | grep system.hardware (397 bytes, text/plain)
2008-01-04 04:03 UTC, Michel Lind
no flags Details

Description Matthew Saltzman 2007-08-24 19:48:34 UTC
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-2.6.22.4-65.fc7 and all previous F7 kernels

How reproducible:
Always

Steps to Reproduce:
1. Click suspend from the GNOME power manager or run pm-suspend from console
2. Sit back and watch
3.
  
Actual results:
Machine suspends for a few seconds, then resumes by itself.

Expected results:
Machine should suspend until resumed by the user pressing the power button or
other method.

Additional info:
Excerpt from /var/log/messages attached.

Comment 1 Matthew Saltzman 2007-08-24 19:48:34 UTC
Created attachment 172451 [details]
Excerpt from /var/log/messages spanning suspend/resume.

Comment 2 Matthew Saltzman 2007-09-29 21:42:48 UTC
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.

Comment 3 Jan Hutař 2007-10-18 20:41:50 UTC
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:

http://people.freedesktop.org/~hughsient/quirk/

Comment 4 Matthew Saltzman 2007-10-19 17:42:58 UTC
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.

Comment 5 Jan Hutař 2007-10-20 15:29:44 UTC
I see. So what about disconnecting external stuff (network) - maybe it is a 
WakeOnLan stuff which wakes your system (happened to me).

Comment 6 Matthew Saltzman 2007-10-20 21:25:10 UTC
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.

Comment 7 Matthew Saltzman 2007-12-21 23:56:57 UTC
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.

Comment 8 Matthew Saltzman 2007-12-26 23:05:15 UTC
I used the kernel-2.6.23.9-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.

Comment 9 Jan Hutař 2008-01-02 10:07:38 UTC
(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.

Comment 10 Michel Lind 2008-01-04 04:03:12 UTC
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.

Comment 11 Jan Hutař 2008-01-04 07:50:25 UTC
Hello Michel,
My T61 with Intel graphics suspends/resumes correctly with updated F8 
(hal-0.5.10-1.fc8.x86_64, hal-info-20071030-1.fc8.noarch).

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 
system correctly?

pm-suspend --quirk-s3-mode

or

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)

http://people.freedesktop.org/~hughsient/quirk/

Comment 12 Matthew Saltzman 2008-01-08 15:51:24 UTC
(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.

Comment 13 Matthew Saltzman 2008-01-08 23:31:21 UTC
Bug #404621 looks like it might be relevant.

Comment 14 Jan Hutař 2008-01-09 12:11:29 UTC
I see, you used spec file from kernel-2.6.23.9-85.fc8 SRPM to build a vanilla 
kernel. I have no experiences with this.

Comment 15 Matthew Saltzman 2008-01-09 19:19:47 UTC
Based on the discussion at
http://www.redhat.com/archives/fedora-devel-list/2007-December/msg01531.html and
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
number.)

Comment 16 Michel Lind 2008-01-10 18:13:03 UTC
Hi Jan,

Shouldn't this quirk listing already match my hardware?

      <match key="system.hardware.product"
prefix_outof="1702;1704;1706;1709;6363;6364;7658;8919;7767C3U">

compared against

  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
screen

s3-bios and vbemode-restore: bounces, everything ok on resume

Comment 17 Jan Hutař 2008-01-10 21:26:36 UTC
Hello Michel,
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://
www.gnome.org/projects/gnome-power-manager/)

According to 20-video-quirk-pm-lenovo.fdi, you should be able to correctly 
suspend with:

pm-suspend --quirk-s3-bios --quirk-s3-mode

Comment 18 Matthew Saltzman 2008-01-10 23:38:50 UTC
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
again.

Comment 19 Michel Lind 2008-01-11 22:47:45 UTC
Seconding Matthew here. I've tried pm-suspend manually, with both s3-bios and
s3-mode.

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
suspend either.

Comment 20 Matthew Saltzman 2008-01-13 17:52:43 UTC
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
<ctrl>-<alt>-<F1>, <ctrl>-<alt>-<del>.

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
- s3-mode and s3-bios
- s3-mode, s3-bios, and vbemode-restore



Comment 21 Michel Lind 2008-01-13 18:15:51 UTC
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?

Comment 22 Matthew Saltzman 2008-01-13 19:21:55 UTC
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.



Comment 23 Michel Lind 2008-01-27 17:21:46 UTC
Per mailing list discussion:

https://www.redhat.com/archives/fedora-devel-list/2008-January/msg02721.html

it seems that the problem is resolved:

  Edit /etc/pm/config.d/unload_modules

  SUSPEND_MODULES="ehci_hcd ohci_hcd"

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)

Comment 24 Matthew Saltzman 2008-01-29 22:24:45 UTC
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?

Comment 25 Matthew Saltzman 2008-01-29 22:27:05 UTC
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
hibernate.

Comment 26 Ed Swierk 2008-01-29 23:37:34 UTC
(In reply to comment #23)
> 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).

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?


Comment 27 Michel Lind 2008-01-30 17:54:43 UTC
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

Comment 28 Chris Weyl 2008-05-15 01:02:59 UTC
Still broken out of the box in F-9 on my T61, non-proprietary driver.

Comment 29 Ed Swierk 2008-08-28 16:26:24 UTC
SUSPEND_MODULES="ehci_hcd" fixes the immediate-resume-after-suspend problem on F9 on my T61 with Intel graphics and wireless.

Comment 30 Michel Lind 2008-08-28 17:32:21 UTC
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

Comment 31 Bug Zapper 2008-11-26 07:42:48 UTC
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 32 Ed Swierk 2008-12-16 05:19:56 UTC
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).

Comment 33 Matthew Saltzman 2009-01-07 21:22:07 UTC
The suspend-bounce problem appears to be solved in F10.

Comment 34 Bug Zapper 2009-01-09 07:13:29 UTC
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.


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