[Nouveau] [Bug 55450] [NV17] nouveau driver fails to restore screen content / video mode after resume from s2ram

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=55450

--- Comment #12 from Emil Velikov <emil.l.velikov at gmail.com> ---
(In reply to comment #11)
> In deed, it is now a kernel issue (... and I doubt that it previously was)!
> I have tried to s2ram from init=/bin/bash with mount -t sysfs none /sys:
Not sure if you need anything as fancy as this

Appending " 3" to your kernel command line (grub, lilo or whichever you use)
should default to runlevel 3, thus no X would ever be attempted.

> * s2ram -nofbsuspend
Not sure I've seen this option. Then again not sure that I've seem this program
either. 

>From http://old-en.opensuse.org/S2ram
> ... s2ram is deprecated ...Instead, use a kernel with KMS drivers where suspend should just work

Please try a plain pm-suspend or even 
$ echo mem > /sys/power/state

>   result: bluescreen; sysrq-keys are not working
> * nouveau.modeset=0; s2ram
>   result: text console is restored and almost readable; however sysrq-keys
> are still not working.
> 
This is "amazing" :)
Can you blacklist nouveau and see if sysrq-keys will work after s2r ? If it
does not there is nothing we can do :'(

> kernel-3.11.3-1.1-default
> 
> (I would wonder if you still needed libdrm, Mesa version by now; there will
> be no pm-suspend dmesg on init=/bin/bash). Should I re-post on kernel.org?
Your initial report did not indicate if the issue happens without X -> the
request for libdrm... etc

If plain VT is not working, we should start from there. See the above
suggestions.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20131016/f065fafd/attachment.html>