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:

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

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

(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.

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.

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/

(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-2.6.23.9-85.fc8 SRPM to build a vanilla 
kernel. I have no experiences with this.

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.)

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

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

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.

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.

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

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:

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)

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
hibernate.

(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?

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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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.