Red Hat Bugzilla – Bug 238342
suspend to ram hangs Dell 700m laptop
Last modified: 2013-01-10 05:18:33 EST
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):
Steps to Reproduce:
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
the first kernel that don't work is
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
> > 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:
(BLAG is a Fedora respin)
The oldest and some kernels I had to recompile (found only the SRPMS) are
available here too:
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.2911.fc7 Not working
1.2910 is :
Thu Jan 11 2007 Kristian Høgsberg <email@example.com>
- Add and enable alternative firewire stack.
And indeed with 2.6.21-1.3116.fc7 and
$ rmmod fw_ohci fw_core
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
> $ pm-suspend
> the box returns to X after resume, while without the rmmod command resume
> 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:
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">
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:
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: