From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7 Description of problem: With kernel-2.6.12-1.1456_FC4, echo -n mem >/sys/power/state puts the system in standby, with the power LED pulsating. Pressing the power switch wakes the system up. With kernel-2.6.13-1.1526_FC4 up to 2.6.14-1.1644_FC4, the system suspends OK, but pressing the power button results in the power LED coming back on, but there is no other activity. The screen remains off, the keyboard is unresponsive, there is no hard drive activity, and nothing is logged to disk. The system has to be powered off and rebooted. Version-Release number of selected component (if applicable): kernel-2.6.13-1.1526_FC4.i686.rpm and later How reproducible: Always Steps to Reproduce: 1. echo -n mem >/sys/power/state 2. Try to wake laptop back up after it sucessfully suspends 3. Actual Results: System remains halted or hung. Expected Results: System should wake back up when power button is pressed. Additional info: The problem is related to the kernel preemption code. Recompiling kernel 2.6.14-1.1644_FC4 with no forced preemption (CONFIG_PREEMPT_NONE=y) restores succesful suspend/resume. Changing the preemption option back to voluntary (CONFIG_PREEMPT_VOLUNTARY=y) reproduces the failure to resume from suspend to mem. Is there, or can there be a kernel run-time parameter to turn the preemption off for us laptop users? Google shows lots of similar complaints but few answers...
I have the same no-video-resume (but system otherwise restores and responds to keyboard and network requests) problem. I'm running Fedora Core 4's kernel-2.6.14-1.1653_FC4, and thought I'd follow your advice. Unfortunately, in the config file, kernel-2.6.14-i686.config it already has: CONFIG_PREEMPT_NONE=y So that makes me think CONFIG_PREEMPT_NONE is not at the bottom of my trouble. I have Dell Latitude D800, Nvidia GeForce FX Go5200 video, and ipw2200.
Mark, does the latest update FC4 kernel in updates-testing make things work for you? As Paul points out, the preemption has been disabled in this build as a test . Paul, it's highly likely you have a unrelated (and common) problem. Waking up video chipsets on resume is highly problematic. Due to the lack of documentation, we have no idea how to bring the chip back from the dead, so it remains off. One trick that works for a lot of people is to re-run the video BIOS power-on init code. Google for 'vbetool', and experiment with that in your suspend/resume scripts.
Hi Dave - Yes, 2.6.15-1.1823_FC4 testing suspends and resumes OK on this Dell 2200. Paul - If it's any help, I run 'chvt 1' (switches away from X and to a console) in the suspend script right before 'echo -n mem >/sys/power/state', and then just after the echo I run 'vbetool post' to reset the video chipset. Mark.
bizarre. I've no idea why the voluntary preemption is breaking this.
Hi Dave - The offending module appears to be yenta_socket. Boot kernel 2.6.14-1.1644_FC4 single user. lsmod shows yenta_socket loaded but unused. Run suspend script, system cannot be woken up. Boot same kernel in single user, rmmod yenta_socket, run suspend script and the system suspends/resumes correctly. If you think of anything to change, I'd be happy to test it here.
good detective work, that narrows the scope a little.
This is a mass-update to all currently open kernel bugs. A new kernel update has been released (Version: 2.6.15-1.1830_FC4) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. Thank you.
(In reply to comment #7) > This is a mass-update to all currently open kernel bugs. > > A new kernel update has been released (Version: 2.6.15-1.1830_FC4) > based upon a new upstream kernel release. > > Please retest against this new kernel, as a large number of patches > go into each upstream release, possibly including changes that > may address this problem. > > This bug has been placed in NEEDINFO_REPORTER state. > Due to the large volume of inactive bugs in bugzilla, if this bug is > still in this state in two weeks time, it will be closed. > > Should this bug still be relevant after this period, the reporter > can reopen the bug at any time. Any other users on the Cc: list > of this bug can request that the bug be reopened by adding a > comment to the bug. > > If this bug is a problem preventing you from installing the > release this version is filed against, please see FCMETA_INSTALL. > > Thank you. > (In reply to comment #7) > This is a mass-update to all currently open kernel bugs. > > A new kernel update has been released (Version: 2.6.15-1.1830_FC4) > based upon a new upstream kernel release. > > Please retest against this new kernel, as a large number of patches > go into each upstream release, possibly including changes that > may address this problem. > > This bug has been placed in NEEDINFO_REPORTER state. > Due to the large volume of inactive bugs in bugzilla, if this bug is > still in this state in two weeks time, it will be closed. > > Should this bug still be relevant after this period, the reporter > can reopen the bug at any time. Any other users on the Cc: list > of this bug can request that the bug be reopened by adding a > comment to the bug. > > If this bug is a problem preventing you from installing the > release this version is filed against, please see FCMETA_INSTALL. > > Thank you. > Hi Dave, The 2.6.15-1.1830_FC4 kernel also suspends/resumes properly on my Inspiron 2200. Not surprising, as it's configured with CONFIG_PREEMPT_NONE=y. Mark.
[This comment added as part of a mass-update to all open FC4 kernel bugs] FC4 has now transitioned to the Fedora legacy project, which will continue to release security related updates for the kernel. As this bug is not security related, it is unlikely to be fixed in an update for FC4, and has been migrated to FC5. Please retest with Fedora Core 5. Thank you.
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
(In reply to comment #10) Hi Dave, The bug appears to be gone in 2.6.18-1.2200.fc5, it now suspends/resumes properly with VOLUNTARY_PREEMPT=Y. Thanks, Mark.