Bug 523190

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.

Just wonder if suspend/resume works with LiveCD? 

I also installed rawhide locally. On resume I've got flicker and nothing else.

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

Created attachment 361620 [details]
/var/log/messages after suspend-resume cycle

Hope this could help

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.

Created attachment 362184 [details]
dmesg >dmesg.txt 2>&1

dmesg 2>dmesg.txt is empty

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!

Thank you, for looking into this!

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.

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.

Created attachment 362669 [details]
suspend/resume cycle with 2.6.31.1-46 and nouveau.vbios=pramin

Now I can see a mouse pointer on black screen on resume.

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?

Suspend/resume from runlevel 3 works as expected.

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.

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

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.

Out of curiosity, can you blindly (or over ssh) execute "xgamma -r 1.0" somewhere after resuming to your session?

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

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

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.

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.

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.

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

*** Bug 532537 has been marked as a duplicate of this bug. ***

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?

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?

1.7.0-5 is tagged, and there was a relevant fix in 1.7.0-2:

* Thu Oct 08 2009 Adam Jackson <ajax> 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

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

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

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.