Bug 230675 - D620: Does not Survive Suspend to Memory/Resume
D620: Does not Survive Suspend to Memory/Resume
Product: Fedora
Classification: Fedora
Component: pm-utils (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Phil Knirsch
Fedora Extras Quality Assurance
Depends On:
Blocks: D620_Tracker
  Show dependency treegraph
Reported: 2007-03-01 20:34 EST by Warren Togami
Modified: 2015-03-04 20:18 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-15 04:27:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Warren Togami 2007-03-01 20:34:13 EST
(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
Comment 1 Warren Togami 2007-03-05 21:05:12 EST
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

(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)
Comment 2 Sitsofe Wheeler 2007-03-16 06:50:20 EDT
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...
Comment 3 Sitsofe Wheeler 2007-03-16 07:01:24 EDT
(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:
and http://suspend.cvs.sourceforge.net/suspend/suspend/whitelist.c?view=markup )
Comment 4 James Ralston 2007-03-29 15:09:32 EDT
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
Comment 5 James Ralston 2007-04-04 17:50:37 EDT
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.
Comment 6 James Ralston 2007-05-21 10:39:29 EDT
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.
Comment 7 Richard Hughes 2007-05-24 06:31:08 EDT
Can you also have a look at http://people.freedesktop.org/~hughsient/quirk/ if
you are having problems please - thanks.
Comment 8 Nikos Charonitakis 2007-05-25 05:28:30 EDT
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
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.
Comment 9 James Ralston 2007-05-25 11:07:27 EDT
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.)
Comment 10 James Ralston 2007-06-17 03:43:40 EDT
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).
Comment 11 James Ralston 2007-06-18 01:59:50 EDT
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

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...
Comment 12 James Ralston 2007-06-18 03:41:50 EDT
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.)
Comment 13 James Ralston 2007-07-06 19:32:43 EDT
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.
Comment 14 James Ralston 2007-07-19 10:35:51 EDT
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?
Comment 15 Rezwanul Kabir 2007-07-19 11:22:22 EDT
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.
Comment 16 James Ralston 2007-07-23 01:29:54 EDT
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-, 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, or else needs even more fixes.  :(
Comment 17 James Ralston 2007-08-24 16:08:13 EDT
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?
Comment 18 Nikos Charonitakis 2008-03-10 18:05:47 EDT
With (applies also to recent kernels 2.6.23.x) d620 fails to
wake from suspend.
Hibernate also fails to sleep with endless disk activity...
Comment 19 Warren Togami 2008-03-10 18:17:28 EDT
I don't have this laptop anymore.  I returned it because I was very unhappy with it.

Please test the latest kernel from here.
Comment 20 James Ralston 2008-03-10 18:33:12 EDT
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.
Comment 21 Nikos Charonitakis 2008-03-10 19:05:38 EDT
My d620 has nvidia graphics if this make any difference... For me (at somepoint)
F7 worked. F8 and F9-Alpha always failed.
Comment 22 Nikos Charonitakis 2008-03-31 12:40:34 EDT
After some google searches i found a solution that works (d620 with nvidia card)

edited this file:

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 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>

and then reboot.
Comment 23 Bug Zapper 2008-05-13 22:39:24 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 24 Matthew Garrett 2008-11-03 07:29:20 EST
Should be fixed in rawhide
Comment 25 Bug Zapper 2009-06-09 18:29:20 EDT
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: 
Comment 26 Bug Zapper 2009-07-15 04:27:24 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.