Hide Forgot
kernel-2.6.20-1.2953.fc7 (No X running.) 1) echo mem > /sys/power/state 2) wait until it has suspended 3) power on button It attempts to power on, but the LCD screen doesn't turn on. Ping on the network doesn't work, so it appears that it doesn't survive suspend/resume.
I just remembered a conversation with mdomsch. You might want to see if disabling USB (especially the ahci driver) allows it to survive a suspend and resume. (You might want to test this while plugged into an external monitor, because the LCD screen might not be coming back properly after resume... perhaps similar to Bug #230670)
The "computer doesn't power screen back on after suspend" is a well known problem with a large number of differing solutions depending on the machine/bios/graphics card in question. See http://en.opensuse.org/S2ram for the SUSE list of current workarounds...
(PS: Dell machines almost always crash when using s2ram's -a option. It seems that you will never get any help from the BIOS when it comes to saving or restoring the graphics state. It has been reported that this machine needs the -p -m options to suspend and resume correctly: http://www.mail-archive.com/suspend-devel@lists.sourceforge.net/msg01574.html and http://suspend.cvs.sourceforge.net/suspend/suspend/whitelist.c?view=markup )
I have a Dell Latitude D600, and the exact same thing appears to be happening to me. I didn't have any problems when I was running FC6 on my laptop. As soon as I installed FC7test1, however, about 30% of the time, resuming from a suspend-to-memory hangs. The hang (when it occurs) is not simply a case of the LCD display not turning on; rather, the machine completely wedges. A Ctrl-Alt-Delete is ignored; pressing the power button (which would normally trigger a shutdown and poweroff) is ignored. The only way to recover is to hold down the power button for 4 seconds until the BIOS powers off the system. Again, I had zero problems with FC6. This only started happening when I installed FC7test1. I have kept up-to-date w/ Rawhide, but all kernels released for FC7test1 (and FC7test2) have this problem. I installed FC7test1 on my laptop before the 2.6.20 kernel was released for FC6, so unfortunately, I don't know if the 2.6.20 kernel is the source of the problem. I can't easily test this, either, as I'm out of disk space; I'd have to wipe my FC7test install and reinstall FC6. I could do that if I really had to, but I'm hoping that won't be necessary. I'll try enabling /sys/power/pm_trace and seeing if I get any useful syslog information.
Alas, although enabling /sys/power/pm_trace seems to provide a lot more information, none of that information makes it to syslog when the machine wedges on resume. If I can scrounge up a DB9 crossover cable from our network guys, I'll try setting up a serial console, and seeing if I get any useful information over it.
Although I can't speak for Warren, after extensive use, I can say that I haven't seen this problem with my Latitude D600 since about the time that the first 2.6.21 kernel hit Rawhide. At about the same time, I noticed that the resume behavior changed: upon resume, I now often catch some text being printed on a tty before the display flips back to X. I never saw that before. For at least the D600, I am confident that recent kernels manage to avoid the "wedge on resume" problem.
Can you also have a look at http://people.freedesktop.org/~hughsient/quirk/ if you are having problems please - thanks.
I have tested fedora development and -3190 kernel with d620: A) hibernate works only when i dont use iwl3945 wireless driver B) suspend can complete first step but cant resume (propably cant bring up lcd monitor) C) suspend with wireless iwl3945 enabled also hangs computer at the first stage. I ve tried some quirks with -3189 but none of them was effective.
Alas, starting with (I believe) kernel-2.6.21-1.3175.fc7, I'm again seeing hangs on resume from suspend. HAL knows about the quirks for my laptop (Dell Latitude D600), so I strongly suspect something changed recently with the kernel. (It's possible that the HAL quirks never fixed my problem, but I would've had to go about 3 weeks--with multiple suspends per day--without chancing upon a hang on resume. It's possible, but not statistically likely, as when the problem is occurring I see hangs on resume about 30% of the time.)
Here's the pm_trace output from multiple hang-on-suspend incidents on my Dell Latitude D600 from 2007-05-29 through today: Linux version 2.6.21-1.3194.fc7 ... Using IPI No-Shortcut mode Magic number: 0:798:462 hash matches drivers/base/power/resume.c:46 drivers/rtc/hctosys.c: unable to open rtc device (rtc0) Linux version 2.6.21-1.3189.fc7 ... Using IPI No-Shortcut mode Magic number: 0:798:12 hash matches drivers/base/power/resume.c:46 drivers/rtc/hctosys.c: unable to open rtc device (rtc0) Linux version 2.6.21-1.3194.fc7 ... Using IPI No-Shortcut mode Magic number: 0:798:695 hash matches drivers/base/power/resume.c:46 hash matches device 0000:00:00.0 drivers/rtc/hctosys.c: unable to open rtc device (rtc0) Linux version 2.6.21-1.3194.fc7 ... Using IPI No-Shortcut mode Magic number: 0:798:379 hash matches drivers/base/power/resume.c:46 drivers/rtc/hctosys.c: unable to open rtc device (rtc0) Linux version 2.6.21-1.3194.fc7 ... Using IPI No-Shortcut mode Magic number: 0:798:379 hash matches drivers/base/power/resume.c:46 drivers/rtc/hctosys.c: unable to open rtc device (rtc0) Linux version 2.6.21-1.3194.fc7 ... Using IPI No-Shortcut mode Magic number: 0:798:12 hash matches drivers/base/power/resume.c:46 drivers/rtc/hctosys.c: unable to open rtc device (rtc0) Linux version 2.6.21-1.3194.fc7 ... Using IPI No-Shortcut mode Magic number: 0:798:379 hash matches drivers/base/power/resume.c:46 drivers/rtc/hctosys.c: unable to open rtc device (rtc0) For the third hang, device 0000:00:00.0 seems like it is: 00:00.0 Host bridge: Intel Corporation 82855PM Processor to I/O Controller (rev 03) Again, everything was working perfectly with earlier kernel versions: I'm fairly certain that 2.6.21-1.3116 worked, and 2.6.21-1.3194 is definitely broken. I'm not sure about the intervening kernels (2.6.21-1.3149, 2.6.21-1.3163).
After yet more experimenting, I've discovered that if I suspend to ram without X running, resuming doesn't hang, although the LCD panel stays off. However, if I then attempt to start X (via running startx), the system hangs. So, it would appear that something in the video subsystem isn't being restored properly. The hal-info package was updated to the 20070516 release on or shortly after 2007-05-17. This is *awfully* close to when my hang-on-resume problems started up again. Is there any chance that Latitude D600 quirks aren't being properly applied in hal-info-20070516? Additionally, kernel 2.6.21-1.3228 hangs on the first X11 activity after a resume every single time; I've never gotten this kernel to work. I'll experiment with trying different quirks, but the frustrating thing is that this *was* working reliably until recently...
The only thing I was able to find is that hal-info has: power_management.quirk.no_fb = true (bool) ...but pm-suspend has no corresponding --quirk-no-fb option. But seems like this has been the case for multiple months. s2ram lists VBE_POST|VBE_SAVE|NOFB for a Dell Latitude D600, which are the same quirks hal-info lists, and no other quirks I tested helped. At this point, I've exhausted pretty much everything I can think of to debug. Further suggestions are welcome. (I'm at a conference this week, and it's a huge PITA to not be able to suspend my laptop, so I'm really motivated to get suspend-to-RAM working.)
I just updated to the 2.6.21-1.3255.fc7 test kernel (which claims to have some suspend-related ACPI fixes in it), and at least initially, resuming from suspend-to-memory isn't hanging anymore. (Woohoo!) I'll test further and report back.
Alas, I can still reproduce hangs on resuming from suspend-to-memory. It seems to happen about 50% of the time. The hangs seem more likely to happen when I change the docking state while suspended. (I.e., suspend while docked then unsuspend while undocked; suspend while undocked and then resume while docked.) Is this a known problem case?
This is the warm dock/undock issue you are bumping into. There is no support for it in the kernel yet, as far as I know. You may want to work with the dock driver developer from Intel ,Kristen Accardi, on that.
Hmmm, strange; I've actually managed to warm dock/undock many times. But if there's no specific support for that, then that would probably explain the hangs I was seeing with 2.6.21-1.3255.fc7; I don't think I saw any hangs when I didn't change the docking state. Alas, however, I used the past tense in the previous paragraph because I've since updated to kernel-2.6.22.1-27.fc7, which hangs on resume *every* time, always in the same place: NET: Registered protocol family 17 Using IPI No-Shortcut mode Magic number: 0:109:379 hash matches drivers/base/power/resume.c:51 drivers/rtc/hctosys.c: unable to open rtc device (rtc0) Freeing unused kernel memory: 240k freed So, either the fixes that went into 2.6.21-1.3255.fc7 were undone in 2.6.22.1-27.fc7, or else 2.6.22.1-27.fc7 needs even more fixes. :(
An update: for every 2.6.22 series kernel I've used so far, suspending/resuming works perfectly. In fact, even warm [un]docking works perfectly now. (I'm not sure if that's supposed to work in 2.6.22, or it's just a happy coincidence; in either case, I'm not complaining.) Warren, do the 2.6.22 series kernels work for you?
With 2.6.24.3-12.fc8 (applies also to recent kernels 2.6.23.x) d620 fails to wake from suspend. Hibernate also fails to sleep with endless disk activity...
I don't have this laptop anymore. I returned it because I was very unhappy with it. http://koji.fedoraproject.org/packages/kernel/2.6.24.3/ Please test the latest kernel from here.
Again, as a reference point, for my Latitude D600, all suspend/resume operations (including warm docking/undocking) have worked perfectly since 2.6.22. Even Rawhide (which I've been running since F9 alpha came out) has been mostly stable in terms of suspend/resume.
My d620 has nvidia graphics if this make any difference... For me (at somepoint) F7 worked. F8 and F9-Alpha always failed.
After some google searches i found a solution that works (d620 with nvidia card) http://klamstwo.org/evad/archives/55 edited this file: /usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-dell.fdi have to change these lines: <match key="system.hardware.product" contains_outof="D620;D800"> <merge key="power_management.quirk.vbe_post" type="bool">true</merge> <merge key="power_management.quirk.vbestate_restore" type="bool">true</merge> </match> to: <match key="system.hardware.product" contains_outof="D620;D800"> <match key="info.linux.driver" string="nvidia"> <merge key="power_management.quirk.none" type="bool">true</merge> </match> </match> and then reboot.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Should be fixed in rawhide
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. 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 '9'. 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 9'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 9 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
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 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.