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.
Created attachment 67849 [details] /var/log/messages
Created attachment 67850 [details] Xorg.0.log
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.
No response to re-test request for over a month. Closing as invalid.
oops; have overlooked this bug; wanna re-test, soon; hope that some boot cd will do it.
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).
Created attachment 87693 [details] Xorg.0.log
Created attachment 87700 [details] /var/log/messages .. though with the proprietary driver it had been working on much elder kernels.
I don`t see how that with log_buf_len=1M should work as the pure dmesg will be lost after a cold start.
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?
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?
(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.
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
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.
issue moved to kernel.org: https://bugzilla.kernel.org/show_bug.cgi?id=63171
(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.