Bug 523190 - display stays off after resume
display stays off after resume
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Ben Skeggs
Fedora Extras Quality Assurance
:
: 532537 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-14 08:47 EDT by Yulia Kopkova
Modified: 2010-12-05 01:25 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-05 01:25:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/var/log/messages after suspend-resume cycle (71.08 KB, text/plain)
2009-09-18 05:55 EDT, Yulia Kopkova
no flags Details
dmesg >dmesg.txt 2>&1 (46.67 KB, text/plain)
2009-09-23 04:03 EDT, Yulia Kopkova
no flags Details
normal boot with 2.6.31.1-46 and nouveau.vbios=pramin (46.82 KB, text/plain)
2009-09-25 08:52 EDT, Yulia Kopkova
no flags Details
suspend/resume cycle with 2.6.31.1-46 and nouveau.vbios=pramin (20.44 KB, application/octet-stream)
2009-09-25 08:53 EDT, Yulia Kopkova
no flags Details
suspend + resume dmesg log, using nouveau.vbios=pramin (17.90 KB, text/plain)
2009-10-06 07:19 EDT, Paul W. Frields
no flags Details

  None (edit)
Description Yulia Kopkova 2009-09-14 08:47:47 EDT
Description of problem:
During Nouveau Test Day, the suspend test
[https://fedoraproject.org/wiki/QA:Testcase_nouveau_suspend] failed with nVidia Corporation G70 [GeForce Go 7600] (rev a1). Suspension occurred as expected, but during resuming display stays off.

However, suspend/resume works fine with F11.

Version-Release number of selected component (if applicable):
http://adamwill.fedorapeople.org/20090909_test_day_images/testday-20090909-x86_64.iso

How reproducible:
Always

Steps to Reproduce:
1. boot with LiveCD
2. suspend
3. resume
  
Actual results:
display stays off after resume

Expected results:
display switch on and system restored.

Additional info:
Comment 1 Ben Skeggs 2009-09-15 18:21:41 EDT
I'm really not sure how suspend/resume could have possibly worked in F11 with the nouveau driver, but anyway..  Are you able to post your /var/log/messages from after a failed resume.

Thanks.
Comment 2 Yulia Kopkova 2009-09-16 11:56:05 EDT
Just wonder if suspend/resume works with LiveCD? 

I also installed rawhide locally. On resume I've got flicker and nothing else.
Comment 3 Adam Williamson 2009-09-17 16:42:23 EDT
you may be able to get the log 'blind' and dump it to a USB stick or similar, though, or ssh into the machine and get it that way?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 4 Yulia Kopkova 2009-09-18 05:55:05 EDT
Created attachment 361620 [details]
/var/log/messages after suspend-resume cycle

Hope this could help
Comment 5 Ben Skeggs 2009-09-23 02:16:41 EDT
Hmm, can you boot normally, open a terminal and run "dmesg 2>dmesg.txt" and upload dmesg.txt here please?  I want to see the messages from nouveau as it loads.
Comment 6 Yulia Kopkova 2009-09-23 04:03:27 EDT
Created attachment 362184 [details]
dmesg >dmesg.txt 2>&1

dmesg 2>dmesg.txt is empty
Comment 7 Ben Skeggs 2009-09-23 04:46:12 EDT
oops, yeah imagine the 2 isn't there :)

Hmm yet another case where the PCI ROM image appears to be incomplete, yay.  OK, I'll patch some stuff into a future kernel to help debug this, and a way to override the VBIOS image selection.

Thanks!
Comment 8 Yulia Kopkova 2009-09-23 04:53:12 EDT
Thank you, for looking into this!
Comment 9 Ben Skeggs 2009-09-25 06:03:35 EDT
If you update to the kernel at http://koji.fedoraproject.org/koji/taskinfo?taskID=1705865 you'll be able to pass nouveau.vbios=pramin in your boot options.  Hopefully this'll get you a more reliable VBIOS image, and working suspend/resume.
Comment 10 Yulia Kopkova 2009-09-25 08:52:00 EDT
Created attachment 362668 [details]
normal boot with 2.6.31.1-46 and nouveau.vbios=pramin

I've tried kernel-2.6.31.1-46.fc12.x86_64 nouveau.vbios=pramin option. 
Now I can see a mouse pointer on black screen. :)

Here are logs.
Comment 11 Yulia Kopkova 2009-09-25 08:53:48 EDT
Created attachment 362669 [details]
suspend/resume cycle with 2.6.31.1-46 and nouveau.vbios=pramin
Comment 12 Yulia Kopkova 2009-09-25 08:54:57 EDT
Now I can see a mouse pointer on black screen on resume.
Comment 13 Ben Skeggs 2009-09-25 10:50:23 EDT
Well, progress!  I have no idea why you're looking at a blank screen though, the GPU seems happy enough in the logs.  Are you able to suspend/resume from runlevel 3?
Comment 14 Yulia Kopkova 2009-09-25 11:05:36 EDT
Suspend/resume from runlevel 3 works as expected.
Comment 15 Orion Poplawski 2009-09-30 17:26:37 EDT
Just to comment that nouveau.vbios=pramin cleared up some video corruption I saw during hibernate and after resuming.

xorg-x11-drv-nouveau-0.0.15-13.20090929gitdd8339f.fc12.i686
xorg-x11-server-Xorg-1.6.99.903-1.fc12.i686
kernel-PAE-2.6.31.1-56.fc12.i686

Don't know if this will be made a default at some point, but it helps for me.
Comment 16 Paul W. Frields 2009-10-06 07:19:16 EDT
Created attachment 363815 [details]
suspend + resume dmesg log, using nouveau.vbios=pramin

Pretty sure I'm experiencing the same bug.  

xorg-x11-server-Xorg-1.6.99.903-2.fc12.x86_64
xorg-x11-drv-nouveau-0.0.15-13.20090929gitdd8339f.fc12.x86_64
kernel-2.6.31.1-56.fc12.x86_64

Resume from suspend was working properly around Sept. 19 because I remember being tremendously happy at Software Freedom Day about it (yay, no more nvidia driver!).

I booted with nouveau.vbios=pramin.  After resume, just an X mouse cursor on the screen and blackness.  Changing to a tty yields a blank screen too.  FWIW, if I SSH in and 'killall Xorg', X is regenerated properly *and* I can switch back to a tty and see the display.  This is a laptop, nVidia Corporation GeForce 8400M GS [10de:0427] (rev a1).
Comment 17 Paul W. Frields 2009-10-06 07:24:07 EDT
Argh.  Apparently things work fine with suspend/resume from the GDM login screen and from a test user account.  Something from my session may be at fault; I'm going to sniff around to see what I can figure out.
Comment 18 Ben Skeggs 2009-10-06 18:52:09 EDT
Out of curiosity, can you blindly (or over ssh) execute "xgamma -r 1.0" somewhere after resuming to your session?
Comment 19 Paul W. Frields 2009-10-06 19:10:14 EDT
[pfrields@victoria ~]$ xgamma -r 1.0
-> Red  1.000, Green  1.000, Blue  1.000
<- Red  1.000, Green  1.000, Blue  1.000

No change in the display.  Another data point:  If I remotely execute 'startx -- :1' and then ^C, the original display of stuff on :0 works fine.
Comment 20 Paul W. Frields 2009-10-06 19:11:48 EDT
Note that comment #19 is in the context of the original problem, where the screen is on full brightness, and the mouse cursor appears but neither the background nor the lock dialog appear (although the dialog is running).
Comment 21 Ben Skeggs 2009-10-06 19:18:09 EDT
Yeah, I thought it could be a bug I've seen before (on my laptop actually, it appeared "out of nowhere" in the last week or so) where only the mouse cursor appears and a gamma change fixes the issue.
Comment 22 Paul W. Frields 2009-10-08 01:50:20 EDT
Ben -- I can't explain how comment #19 was the case... but I can fix the problem now by unlocking the screen blind, and running 'xgamma -r 1.0'.  So I think I'm seeing the same problem.

Earlier today after more testing I would have sworn that there was some difference in the behavior between AC power and battery operation, but I can't reproduce it now, so forget that.
Comment 23 Paul W. Frields 2009-11-02 09:38:05 EST
I don't suppose there's been any progress on the gamma problem?  Today is the last day to get things tagged for the F12 RC, I believe.
Comment 24 Ben Skeggs 2009-11-02 18:02:21 EST
Hmm, I no longer see the issue here.  Currently I'm running:

xorg-x11-server-Xorg-1.7.1-2.fc12.x86_64
xorg-x11-drv-nouveau-0.0.15-13.20090929gitdd8339f.fc12.x86_64
kernel-2.6.31.5-96.fc12.x86_64
libdrm-2.4.15-1.fc12.x86_64
Comment 25 Ben Skeggs 2009-11-02 18:06:38 EST
*** Bug 532537 has been marked as a duplicate of this bug. ***
Comment 26 Paul W. Frields 2009-11-02 18:14:32 EST
I"m on the same packages, save this one:

xorg-x11-server-Xorg-1.7.0-1.fc12.x86_64

Where did your update come from?  Something not yet tagged or in daily Rawhide possibly?
Comment 27 Ben Skeggs 2009-11-02 18:33:45 EST
http://koji.fedoraproject.org/koji/buildinfo?buildID=138995.  No, this build isn't tagged yet.  I'm fairly sure 1.7.0-5 has been just recently, maybe worth trying that and confirming we don't need to tag a newer build again?
Comment 28 Adam Williamson 2009-11-02 18:37:13 EST
1.7.0-5 is tagged, and there was a relevant fix in 1.7.0-2:

* Thu Oct 08 2009 Adam Jackson <ajax@redhat.com> 1.7.0-2 - xserver-1.7.0-randr-gamma-restore.patch: Restore CRTC gamma on EnterVT. 

so it would definitely be a good idea to try 1.7.0-5. thanks!

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 29 Bug Zapper 2009-11-16 07:21:28 EST
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 30 Bug Zapper 2010-11-04 06:03:01 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  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 '12'.

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 12'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 12 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 31 Bug Zapper 2010-12-05 01:25:05 EST
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 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.