Summary: | Black screen in KDE after unlocking screen | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | AstroFloyd <AstroFloyd> |
Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED UNMAINTAINED | ||
Severity: | normal | CC: | m.weghorn, public |
Priority: | NOR | Flags: | thomas.luebking:
NVIDIA+
|
Version: | 4.11.3 | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
Xorg system log
Output of glxinfo kwin.dbg kwin.dbg |
Description
AstroFloyd
2014-01-23 11:55:11 UTC
Created attachment 84814 [details]
Xorg system log
Created attachment 84815 [details]
Output of glxinfo
a) press "Alt+Shift+F12" to toggle the compositor off/on when this happens b) try whether you can reproduce this with "full repaint" or "none" tearing prevention c) you're not using a framebuffer console, are you? ("dmesg | grep NVRM" - should print a warning in case) Thanks for picking this up. a) This does nothing for the ~10s black screens. I also noticed that the 'active corners' don't do anything during the 10s events. I haven't been able to try this for the 'indefinite' black screens. b) I get the same result for: Desktop effects: enabled, disabled; Composing type: 1.2, 3.1 or XRender; QT graphics system: Native, Raster; Tearing prevention: Auto, Full scene repaints, none c) AFAIK not; I'm not using graphics on the console. # dmesg | grep NVRM gives: [ 7.116759] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 319.76 <date> When I woke up my laptop today, the screen consisted of triangles made up of bits of window and background like a jigsaw (after the 10s darkness). $ kwin --replace fixed this. I'm not sure it's related. The "short" black screen delay is not related to kwin/compositing but may be the cause to the casual permanent black/distorted screen. In the latter case, toggling compositing twice should "fix" it. Only the permanent error is relevant regarding the other tests (and try tearing prevention at preference) The common reason is likely corrupted VRAM, check whether your BIOS/UEFI allows to repost vieo memory after STR, though a common reason would be the framebuffer console... Last resort might be to pass NVreg_EnableMSI=0 as parameter to the nvidia kernel module, eg. add /etc/modprobe.d/nvidia.conf options nvidia NVreg_EnableMSI=0 If that doesn't help, remove that entry again (see /usr/share/doc/nvidia/README on the topic) I have the same problem. Whenver my PC goes to suspend mode, Kwin hangs with 100% CPU usage (and black scren) after I resume. The workarround is killing kwin and restarting it again. Don't know, whether this helps: glehnhoff@HP8540:/media/Daten/daten/glehnhoff/data_strong$ kwin QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: Quadro FX 880M/PCIe/SSE2 OpenGL version string: 3.3.0 NVIDIA 304.88 OpenGL shading language version string: 3.30 NVIDIA via Cg compiler Driver: NVIDIA Driver version: 304.88 GPU class: Unknown OpenGL version: 3.3 GLSL version: 3.30 X server version: 1.14.5 Linux kernel version: 3.11 Direct rendering: yes Requires strict binding: no GLSL shaders: yes Texture NPOT support: yes Virtual Machine: no kwin(17876) KWin::GlxBackend::present: It seems you are using the nvidia driver without triple buffering You must export __GL_YIELD="USLEEP" to prevent large CPU overhead on synced swaps Preferably, enable the TripleBuffer Option in the xorg.conf Device For this reason, the tearing prevention has been disabled. See https://bugs.kde.org/show_bug.cgi?id=322060 Pattern is "Nvidia Quadro" - weird thing is the claim that this even happens with suspended compositing (Shift+Alt+F12 before suspending) Could be due to some screen reconfiguration. You could "kdebugdialog --fullmode" and redirect all "kwin (1212)" output into some file (/tmp/kwin.dbg) Then check whether the wakeup from STR adds some "screens: <#> desktops: <#>" line Hi Thomas, this is fine with me, but as I am not a Linux guru, please show exactly the commands I have to enter, if you want me to do that. Weird is, that this morning KDE awoke without any problem. I have no idea, why. When the problem happens, Kwin consumption is 100% of the CPU. Beside that I have the same effects as written somewhere else in this bug report. Cheers, gl kdebugdialog is a guitool. just run "kdebugdialog --fullmode" from konsole or krunner (alt+f2), filter for "kwin", select the "1212" entry, and on the right side "file" for every level and pass /tmp/kwin.dbg into the input field below. apply/ok next, cause the problem and then upload /tmp/kwin.dbg here (if you intend to delay the upload a bit, please first copy the file somewhere else, so that its end matches the problem situation.) you can then disable logging in "kdebugdialog" again. Thomas, the error/crash did not come up the last couple of days. The only idea I have why is, that it has been solved with one of my Kubuntu updates. Cheers, gl Created attachment 85132 [details]
kwin.dbg
OK, here we are. It happened again. Attached is the debug file. Unfortunately I do not know whether kdebugdialog still was running :-(
"kdebugdialog" does not have to be running, but the debug output needs to be still redirected. The log ends near showing/activating kdebugdialog, so I assume you've stopped logging at some point? (It would be still active otherwise) Fwiwi: there's no unusual clientArea update logged. Hi Thomas, I do my best but seem to fail. I start kdebugdialog --fullmode, do in the GUI all what you have written, press "Anwenden" (apply) and "OK". The GUI closes. Then I look for a process kdebugdialog and kind find one, nor there is a file created. glehnhoff@HP8540:~$ kdebugdialog --fullmode QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. glehnhoff@HP8540:~$ ps -C kdebugdialog PID TTY TIME CMD glehnhoff@HP8540:~$ Question: - You see, there are some warnings. Do I have a problem with kdebugdialog? - Or do I have to start it with "sudo"? - Or is the file created only, if the problem occurs? As KDE crashed this morning again after "resume" - funny, that I have the feeling it crashes only via overnight - I have to kill kwin in screen 1 and I have to restart it with "DISPLAY=:0 kwin --replace". I looked for a debug-file, there is no. I started kdebugdialog again, as written above, there is still no file, and no process. Cheers, gl Created attachment 85198 [details]
kwin.dbg
I got it. After the crash I found the file. See attached. This time, the system has not been in suspend mode. I only switched to screen 2, the kwin process started consuming 100% of CPU, I switched back to screen 7 and got the funny screen. I killed kwin and started it again, which works.
Thanks for your efforts and sorry for the delay, but "unfortunately" that's not the reason. It though may worth trying to export __GL_YIELD="USLEEP" kwin --replace & (The nvidia blob performs a busy wait for the retrace on swapping, what could be funny if it waits for a swap while you move to VT1) Beyond that, only callgrind (valgrind tool) could tell us more - eventually gdb'ing into kwin from VT1 might give a hint. @AstroFloyd Since Gerhard is "not a Linux guru", could you try either? Do you happen to export __GL_YIELD="USLEEP" anyway? By now we no longer maintain the 4.x branch of KWin. The architecture overall changed a lot - especially in the are of the lock screen. It is to a certain degree unlikely that this bug is still valid for our 5.x series. If you still experience this or a similar bug in 5.x I kindly ask you to report a new bug about this to have all information about the current software version around. Thank you for reporting this bug and help making KDE software better. |