Description of problem: I upgraded from Fedora 6 to 7t4 this morning. Everything went smoothly except suspend to RAM. The running kernel is 2.6.21-1.3116.fc7. When pm-suspend is called, the laptop goes to sleep properly. However when wake up, the system hangs with a blinking capslock led. Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I have the same problem with my HP dv9000 laptop. It seems to go to sleep correctly, but fails to wake up. (My caps-lock doesn't blink) There was a comment in another bugzilla entry that turning cpuspeed off, should help. But with this kernel the system hangs with cpuspeed either on or off.
(In reply to comment #1) > There was a comment in another bugzilla entry that turning cpuspeed off, should > help. But with this kernel the system hangs with cpuspeed either on or off. Turning cpuspeed off? Does that mean the cpu will be at full speed all the time? That would be even worse than the hang.
Same thing on my home workstation - DG965W ATX motherboard with a Core 2 Duo (E6600). Suspend-to-disk seems to work okay though...
Please file separate bugs for all of these. Suspend regressions are usually system specific enough that it makes sense to have different bugs, otherwise, I'll fix the "dell 700m" bug, which have no bearing on the remainder of people filing comments here. "Me too" comments on suspend failures aren't useful unless they're a) the same system and b) adding some extra information not already reported. It may turn out that fixing this bug might actually help some other affected systems too, but it's easier to close two different bugs, than it is to close one bug containing 16 different problems.
(In reply to comment #4) > > b) adding some extra information not already reported. I have similar problem, I am running rawhide and the last kernel that I know works is kernel-2.6.19-1.2906.fc7 the first kernel that don't work is kernel-2.6.19-1.2912.fc7 and of course all later kernels I have tried, about 20 different kernels. I tried to git-bisect the vanilla kernel setting 2.6.20 as bad and 2.6.20-rc1 good to find the problem, however I was unable to reproduce the problem with vanilla kernel, all worked... The problem now is that I don't have any old fedora kernels left (yum clean all). How do I build a old fedora kernel? Checking out from cvs? Or do you have those old kernels available, Dave?
(In reply to comment #5) > Or do you have those old kernels available, Dave? I am also interested in the last working kernel. This issue has blocked me from working productively.
> > Or do you have those old kernels available, Dave? > > I am also interested in the last working kernel. This issue has blocked me from > working productively. I found lots of Fedora kernels here: ftp://ftp.blagblagblag.org/pub/BLAG/linux/70000/en/os/i386/BLAG/RPMS.extras/ (BLAG is a Fedora respin) The oldest and some kernels I had to recompile (found only the SRPMS) are available here too: http://web.phys.ntnu.no/~terjeros/kernels/ I guess you need to use $ rpm -ivh --oldpackage <kernel-package> to install these packages. If you could find the last working and non working kernel among these kernels, the bug could be possible to find.
Ok, I'm making some progress here: kernel-2.6.19-1.2909.fc7 OK kernel-2.6.19-1.2911.fc7 Not working 1.2910 is : Thu Jan 11 2007 Kristian Høgsberg <krh> - Add and enable alternative firewire stack. And indeed with 2.6.21-1.3116.fc7 and $ rmmod fw_ohci fw_core before $ pm-suspend the box returns to X after resume, while without the rmmod command resume hangs hard very soon (< 1 sec) with blinking caps lock light. Could some other people please try this trick? BTW: suspend-to-disk works without the rmmod command.
We are on something: Removing these modules (fw_ohci, fw_core) helped James in bz #238512 too. Don't mean to be harsh, but what happen to the merge-upstream-first policy?
(In reply to comment #8) > And indeed with 2.6.21-1.3116.fc7 and > > $ rmmod fw_ohci fw_core > > before > > $ pm-suspend > > the box returns to X after resume, while without the rmmod command resume hangs hard > very soon (< 1 sec) with blinking caps lock light. > > Could some other people please try this trick? > > BTW: suspend-to-disk works without the rmmod command. I hate 855GME. It has more problems than that. suspend-to-disk hangs the laptop like suspend-to-ram does. The rmmod trick works but the screen is complete black when suspend in console although I know everything is working properly behind the black screen. If suspend in X, after wake up the screen is completely broken (symptom is similar as in bug 189074). These problems might not related to kernel.
This isn't in the blocker list. Does that mean it won't be fixed at all?
Have you tried quirks from this page: http://people.freedesktop.org/~hughsient/quirk/quirk-debug.html
Yeah, I did. I add the following to 20-video-quirk-pm-dell.fdi so that no quirks are used for dell 700M. It's been working great so far. <match key="system.hardware.product" contains="700m"> </match>
where can you see mine "system.hardware.product" ? When I look at some of my logs I can see nx7400 come up, and my laptop is nx7300 - maybe that is the problem.
$ lshal |grep -i inspiron smbios.system.product = 'Inspiron 700m' (string) system.hardware.product = 'Inspiron 700m' (string) system.product = 'Inspiron 700m -1' (string) pci.subsys_product = 'Inspiron 700m' (string)
Guys, there's lots more information about quirks and dmi matching here: http://people.freedesktop.org/~hughsient/quirk/ - I hope it helps.
*** Bug 238512 has been marked as a duplicate of this bug. ***
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp