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