Bug 522393 - Compaq Evo N1020v resume from suspend fails
Summary: Compaq Evo N1020v resume from suspend fails
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jérôme Glisse
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-10 09:35 UTC by Ondrej Zary
Modified: 2018-04-11 10:59 UTC (History)
11 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2011-06-27 14:22:27 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
dmesg (34.34 KB, text/plain)
2009-09-10 09:35 UTC, Ondrej Zary
no flags Details
debugging! (38.23 KB, text/plain)
2009-11-28 04:22 UTC, Joshua Roys
no flags Details
disable displays during suspend (1.41 KB, patch)
2010-05-26 21:49 UTC, Alex Deucher
no flags Details | Diff

Description Ondrej Zary 2009-09-10 09:35:17 UTC
Created attachment 360467 [details]
dmesg

Description of problem:
Suspend to RAM fails on Compaq Evo N1020v. The machine hangs completely, power LED remains on and LCD screen is flashing (maybe an infinite loop?)

Version-Release number of selected component (if applicable):
from Fedora Test Day 20090908 Live CD
(2.6.31-0.212.rc9.git1.fc12.i686)

How reproducible:
Always

Steps to Reproduce:
1. Boot Fedora Test Day 20090908 Live CD
2. Try suspending the machine to RAM
  
Actual results:
Machine hangs with flashing LCD screen. Power LED remains ON.

Expected results:
Machine suspends and power LED starts blinking.

Additional info:
This happens both in X and console (runlevel 3, "echo mem >/sys/power/state"). With KMS disabled, suspend works both X and console (resume does not - but that's probably another bug).

Comment 1 Adam Williamson 2009-09-16 17:36:58 UTC
May be a dupe of 522070, but hard to be sure. reporter, please keep an eye on that one too, just in case...

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 2 Jérôme Glisse 2009-10-14 10:53:37 UTC
What is your GPU ? RS690 (X1250) ? RS480 (X1150|X200,..) ?

Comment 3 Adam Williamson 2009-10-14 22:27:16 UTC
output of 'lspci -nn' would be nice and clear :)

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 4 Ondrej Zary 2009-11-06 13:21:47 UTC
It suspends with desktop-i386-20091105.16.iso (resume does not work).

Comment 5 Adam Williamson 2009-11-06 21:00:30 UTC
what happens when you try to resume, exactly?

also, please answer comment #2...

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 6 Ondrej Zary 2009-11-06 22:37:29 UTC
After pressing power button to resume, the power LED stops blinking (starts to shine continuously). The screen remains blank and machine is hung (no LED reaction on caps lock).

It's ATI Radeon IGP330M/340M/350M (U2) 4337. Hardware list: http://www.smolts.org/client/show/pub_95c990cc-930b-4ef2-9345-b2c361b61683

Comment 7 Adam Williamson 2009-11-07 04:38:06 UTC
Thanks. Can you test suspending/resuming from a console - boot to runlevel 3, login, run 'pm-suspend'? if that fails it's probably a kernel not graphics driver issue...

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 8 Ondrej Zary 2009-11-09 09:55:17 UTC
Yes, it fails to resume in runlevel 3 too. Even with KMS disabled. So it really looks like a kernel thing.

It failed to suspend with KMS before (LED remained on), this now works (LED starts blinking) so it's probably fixed.

Comment 9 Adam Williamson 2009-11-09 17:36:20 UTC
Okay, let's kick this to the kernel then. Adjusting summary. Not sure what info kernel team will need, but lspci or a smolt profile likely wouldn't hurt.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 10 Bug Zapper 2009-11-16 12:11:11 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 11 Joshua Roys 2009-11-28 04:22:01 UTC
Created attachment 374348 [details]
debugging!

Same problem, same graphics card.

http://www.smolts.org/client/show/pub_ade268a6-3f8d-4355-9e8b-b214d391f17f

I've tried unloading every module I can unload and then doing pm-suspend, `echo devices > /sys/power/pm_test' (or any other, core, platform, etc), booting into a debug kernel and setting /proc/acpi/debug_{layer,level} and getting debug info...

Attached is some debugging.

Comment 12 Joshua Roys 2009-12-01 13:26:51 UTC
To be more precise, here are the things I have tried thus far:

1. boot into a debug kernel
2. mount debugfs
3. set some dynamic_debugs via /sys/kernel/debug/dynamic_debug/control
4. set acpi.debug_level=0x88200005
5. set acpi.debug_layer=0xffff0003
6. start netconsole (sigh, no serial console...)
7. (optional) echo something into /sys/power/pm_test (e.g. devices, core, ...)
8. run pm-suspend (or `echo mem > /sys/power/state')

If I do step 7, everything comes back and ssh connections are still up, but the screen stays dark.  I say this is a bug in the radeon driver.  However, if I leave pm_test alone and suspend, I get the same result as the reporter: disks spin up, CD seeks, and then kernel hang.

Comment 13 Joshua Roys 2009-12-02 12:48:52 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=471711#c36 seems similar: same hardware, same problem.

Comment 14 Joshua Roys 2009-12-15 18:41:31 UTC
This http://bugzilla.kernel.org/show_bug.cgi?id=6058#c4 could describe the situation...  in short, some ATI chipsets don't (get told to) set the self-refresh mode on the RAM when entering S3, apparently?

Comment 15 Joshua Roys 2010-01-24 00:16:04 UTC
I think I found the solution, and it's actually kind of simple:

radeontool light off ; echo mem > /sys/power/state ; radeontool light on

pm-suspend works as well...  this has worked multiple times for me from both the console and in X.  I'm guessing this needs a quirk somewhere?  I'll ask the radeon devs on #radeon...

Comment 16 Matěj Cepl 2010-01-24 15:18:36 UTC
I think this rightfully belongs to ATI driver component.

Comment 17 Joshua Roys 2010-05-26 20:52:13 UTC
This is still needed under F13.  (The "light on" after isn't needed and never was, by the way.)

Comment 18 Alex Deucher 2010-05-26 21:23:46 UTC
Does forcing dpms off before suspend help?  It hits the same bits as radeontool light off.  E.g.,

sleep 5; xset dpms force off; echo mem > /sys/power/state

Comment 19 Alex Deucher 2010-05-26 21:49:23 UTC
Created attachment 417042 [details]
disable displays during suspend

Does this patch help?

Comment 20 David Wood 2010-06-29 07:57:12 UTC
Resume from suspend is still a problem on my compaq nx9010 (with the ATI Radeon IGP 330M/340M/350M) running updated F13.  I've tried the two command sequences suggested above and both suspend fine, but the laptop still locks up on resume (e.g. no LED response to caps lock).  Haven't been able to try the patch above.

Comment 21 Bug Zapper 2011-06-02 17:46:06 UTC
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  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 '13'.

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

Comment 22 Bug Zapper 2011-06-27 14:22:27 UTC
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 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.