Bug 55450

Summary: [NV17] nouveau driver fails to restore screen content / video mode after resume from s2ram
Product: xorg Reporter: Elmar Stellnberger <estellnb>
Component: Driver/nouveauAssignee: Nouveau Project <nouveau>
Status: RESOLVED MOVED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium    
Version: 7.6 (2010.12)   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
/var/log/messages
none
Xorg.0.log
none
screenshot after resume from pm-suspend/s2ram
none
Xorg.0.log
none
/var/log/messages none

Description Elmar Stellnberger 2012-09-29 12:39:01 UTC
Last time it stayed on the text console swamping the whole screen with [drm] messages; another time the mouse pointer was working but elsewise console text had stayed on the display (screen content not restored). Had to kill the X server this time; see attachements for further info.
Comment 1 Elmar Stellnberger 2012-09-29 12:45:02 UTC
Created attachment 67849 [details]
/var/log/messages
Comment 2 Elmar Stellnberger 2012-09-29 12:45:22 UTC
Created attachment 67850 [details]
Xorg.0.log
Comment 3 Ilia Mirkin 2013-08-30 22:36:05 UTC
Please re-test with the latest kernel (e.g. 3.11-rc7). If you still have issues, please attach an *uncompressed* log to the issue. See http://nouveau.freedesktop.org/wiki/Bugs/ for instructions on what is needed.
Comment 4 Ilia Mirkin 2013-10-01 16:21:25 UTC
No response to re-test request for over a month. Closing as invalid.
Comment 5 Elmar Stellnberger 2013-10-01 16:35:28 UTC
oops; have overlooked this bug; wanna re-test, soon; hope that some boot cd will do it.
Comment 6 Elmar Stellnberger 2013-10-15 21:11:56 UTC
Created attachment 87692 [details]
screenshot after resume from pm-suspend/s2ram

Unfortunately it does not work yet. The screen is garbeled upon resume from s2ram (can not read the backtrace behind) and the kernel halts without even allowing to shut down by SysRq keys (Alt-PrnScr-S/U/B).
Comment 7 Elmar Stellnberger 2013-10-15 21:12:54 UTC
Created attachment 87693 [details]
Xorg.0.log
Comment 8 Elmar Stellnberger 2013-10-15 21:33:32 UTC
Created attachment 87700 [details]
/var/log/messages

.. though with the proprietary driver it had been working on much elder kernels.
Comment 9 Elmar Stellnberger 2013-10-15 21:37:08 UTC
I don`t see how that with log_buf_len=1M should work as the pure dmesg will be lost after a cold start.
Comment 10 Emil Velikov 2013-10-16 00:06:43 UTC
Elmar

AFAICS we're getting nowhere here, as even basic information is missing, such as
* plain dmesg (before s2r)
* what software are you using - kernel, libdrm, mesa(nouveau-dri) & xf86-video-nouveau
* is this a regression (did it work previously - eg. I've updated XXX and things broke)
* have you tried s2r without loading X?
Comment 11 Elmar Stellnberger 2013-10-16 13:53:05 UTC
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:
* s2ram
  result: colorful stars; sysrq-keys are no more working
* s2ram -nofbsuspend
  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.

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?
Comment 12 Emil Velikov 2013-10-16 18:21:33 UTC
(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.
Comment 13 Emil Velikov 2013-10-16 18:56:07 UTC
On 16/10/13 19:48, Elmar Stellnberger wrote:
> blacklist nouveau?
> I have already "destroyed" my system; yet nouveau still gets laoded:
> modprobe.blacklist=nouveau did not work
> enter "blacklist nouveau" in /etc/modprobe.d/50-blacklist did also not work
> finally renaming noveau.ko to nouveau.ko.bak did not ban the module from
> being loaded either
> 
> so why does all of that d.d. not work?
> can you tell me on what to do?

Without being rude,
1. checked for typos ? I make dozens every day :)
2. igoogleit ? this is the first case that I've heard that one cannot blacklist nouveau(a module in general). I'm assuming that your distro may be handling things in a different(unortodox) manner, thus your frustration
Comment 14 Elmar Stellnberger 2013-10-16 19:20:57 UTC
Well the problem was that nouveau has gone into my initrd. A simple NO_KMS_IN_INITRD="yes" followed by an mkinitrd did the trick. However the just gained test results are not encouraging:
* echo mem >/sys/power/state  without nouveau  -> bluescreen
* echo mem >/sys/power/state  without nouveau and with vga=0  -> funny text screen flicker

I guess we have to post this as a regression at kernel.org. Will have to find the last working kernel (uff. so much broken about Linux at the moment). I guess I would not have reported that as Xorg issue if it were not had been issue-free in console mode.
Comment 15 Elmar Stellnberger 2013-10-16 20:08:47 UTC
issue moved to kernel.org: https://bugzilla.kernel.org/show_bug.cgi?id=63171
Comment 16 Emil Velikov 2013-10-16 20:59:31 UTC
(In reply to comment #14)
> Well the problem was that nouveau has gone into my initrd. A simple
> NO_KMS_IN_INITRD="yes" followed by an mkinitrd did the trick.
From my POV kms drivers in initrd is a very bad idea.

> just gained test results are not encouraging:
> * echo mem >/sys/power/state  without nouveau  -> bluescreen
> * echo mem >/sys/power/state  without nouveau and with vga=0  -> funny text
> screen flicker
> 
I'm suspecting that those two are different (possibly related) issues. Although once we can get a non-lockup system after s2r we can look into the (alleged) nouveau issue.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.