Bug 346116 - Screen hangs, kwin informs about driver recovery, nvidia.
Summary: Screen hangs, kwin informs about driver recovery, nvidia.
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: compositing (show other bugs)
Version: 5.2.2
Platform: Arch Linux Linux
: NOR crash
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-12 19:00 UTC by retired
Modified: 2015-08-08 12:10 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:
thomas.luebking: NVIDIA+


Attachments
journalctl logs for user (1.52 MB, text/plain)
2015-04-12 19:02 UTC, retired
Details
qdbus org.kde.KWin /KWin supportInformation (4.76 KB, text/x-log)
2015-04-12 19:52 UTC, retired
Details
xorg log (43.83 KB, text/x-log)
2015-04-12 19:53 UTC, retired
Details
dmesg, nothing interesting (512 bytes, text/x-log)
2015-04-12 19:54 UTC, retired
Details
journalctl -b after disabling framebuffer (308.75 KB, text/x-log)
2015-04-13 12:10 UTC, retired
Details
journalctl -xb 15.04.15 ~17.21 log (213.06 KB, text/plain)
2015-04-15 15:25 UTC, retired
Details

Note You need to log in before you can comment on or make changes to this bug.
Description retired 2015-04-12 19:00:45 UTC
From time to time I'm expiriencing desktop hang, especially when switching windows. First winows hang, then cursor follows, after few seconds it all comes back to life with message from kwin about driver recovery.
There's not much in logs, beyond: 
Apr 12 20:38:45 archmkd kwin_x11[496]: Using FBConfig 0x1a8 for visual 0xc4
Apr 12 20:38:45 archmkd kwin_x11[496]: kwin_core: 0x20071: Buffer detailed info: Buffer object 2 (bound to GL_ELEMENT_ARRAY_BUFFER_ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory a
Apr 12 20:38:45 archmkd kwin_x11[496]: Using FBConfig 0x119 for visual 0x2d
Apr 12 20:38:45 archmkd kwin_x11[496]: kwin_core: 0x20092: Program/shader state performance warning: Fragment Shader is going to be recompiled because the shader key based on GL state misma
Apr 12 20:38:45 archmkd kwin_x11[496]: Using FBConfig 0x119 for visual 0x2d
Apr 12 20:38:45 archmkd kwin_x11[496]: Using FBConfig 0x1a8 for visual 0xc4
Apr 12 20:38:45 archmkd kwin_x11[496]: QXcbConnection: XCB error: 9 (BadDrawable), sequence: 20205, resource id: 0, major code: 14 (GetGeometry), minor code: 0
Apr 12 20:38:45 archmkd kwin_x11[496]: QXcbConnection: XCB error: 9 (BadDrawable), sequence: 20215, resource id: 0, major code: 14 (GetGeometry), minor code: 0
Apr 12 20:38:45 archmkd kwin_x11[496]: QXcbConnection: XCB error: 9 (BadDrawable), sequence: 20361, resource id: 0, major code: 14 (GetGeometry), minor code: 0
Apr 12 20:38:45 archmkd kwin_x11[496]: QXcbConnection: XCB error: 9 (BadDrawable), sequence: 20362, resource id: 0, major code: 14 (GetGeometry), minor code: 0
Apr 12 20:38:45 archmkd kwin_x11[496]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 20374, resource id: 37749050, major code: 18 (ChangeProperty), minor code: 0
Apr 12 20:38:45 archmkd kwin_x11[496]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 20376, resource id: 37749050, major code: 3 (GetWindowAttributes), minor code: 0
Apr 12 20:38:45 archmkd kwin_x11[496]: QXcbConnection: XCB error: 9 (BadDrawable), sequence: 20377, resource id: 37749050, major code: 14 (GetGeometry), minor code: 0



Reproducible: Sometimes

Steps to Reproduce:
1. Do some some stuff.
2. Switch window from time to time
3. Do more of that.
4. If you are lucky whole screen will freeze.

Actual Results:  
First windows hang, then cursor, then I need to wait few seconds, after that it's all good, kwin informs about driver recovery (stylish I might add).

Expected Results:  
I should not be aware that journal exists and what are logs.

nvidia 346.59
__GL_YIELD="USLEEP" exported from /etc/profile
kwin set to OGL 3.1 with Re-use screen content
Comment 1 retired 2015-04-12 19:02:02 UTC
Created attachment 91992 [details]
journalctl logs for user
Comment 2 Thomas Lübking 2015-04-12 19:17:59 UTC
please

- attach the output of
   qdbus org.kde.KWin /KWin supportInformation
(with the compositor being active)
- attach /var/log/Xorg.0.log
- check "dmesg | grep NVRM" for suspicious warnings/errors

You may also want to try
   export KWIN_EXPLICIT_SYNC=0
   kwin_x11 --replace &


Dev note:
There're 2 "kwin_core: A graphics reset attributable to the current GL context occurred." in the journal.
Comment 3 retired 2015-04-12 19:52:50 UTC
Created attachment 91995 [details]
qdbus org.kde.KWin /KWin supportInformation
Comment 4 retired 2015-04-12 19:53:17 UTC
Created attachment 91996 [details]
xorg log
Comment 5 retired 2015-04-12 19:54:24 UTC
Created attachment 91997 [details]
dmesg, nothing interesting
Comment 6 retired 2015-04-12 19:56:24 UTC
It happens since Plasma 5.1 (that's when I deployed new KDE on my Arch).

I will remember to export KWIN_EXPLICIT_SYNC=0 tomorrow.
Comment 7 Thomas Lübking 2015-04-12 20:21:24 UTC
(In reply to Piotr Kloc from comment #5)

> dmesg, nothing interesting

Au contraire ...

[    2.508311] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  346.59  Tue Mar 31 14:10:31 PDT 2015
[    4.488925] NVRM: Your system is not currently configured to drive a VGA console
[    4.488931] NVRM: on the primary VGA device. The NVIDIA Linux graphics driver
[    4.488934] NVRM: requires the use of a text-mode VGA console. Use of other console
[    4.488937] NVRM: drivers including, but not limited to, vesafb, may result in
[    4.488939] NVRM: corruption and stability problems, and is not supported.

See https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#Disable_framebuffer, fix the setup and see whether the issue still occurs.
Not saying "this is it", but I acutally bet on this message ;-)
Comment 8 retired 2015-04-13 12:09:28 UTC
So I've done things according to wiki. "dmesg | grep NVRM" returns:
[    2.099416] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  346.59  Tue Mar 31 14:10:31 PDT 2015
so it's fixed, I guess.

I have enecountered graphics reset anyway, after opening plaintext file in libreoffice.

Right before 14:02 it hanged, cursor was working though, it was looking more like mouse grab this time. Keyboard wasn't responding.
Comment 9 retired 2015-04-13 12:10:41 UTC
Created attachment 92009 [details]
journalctl -b after disabling framebuffer
Comment 10 retired 2015-04-14 13:16:48 UTC
You won again sir, it runs stable for one day now. It probably was framebuffer. I will report back in one week.
Comment 11 retired 2015-04-15 15:24:27 UTC
There's still something wrong, this time menubar lost it's contents on freeze, kwin recovered with message.
Can I debug it somehow ?
Comment 12 retired 2015-04-15 15:25:29 UTC
Created attachment 92062 [details]
journalctl -xb 15.04.15 ~17.21 log
Comment 13 Thomas Lübking 2015-04-15 15:58:27 UTC
Bug #346218 suggests tunderbird to be the trigger and your log lists firefox (technically equivalent) right before the reset.
Could "mozilla apps" be the cause for you as well?

> menubar lost it's contents on freeze
What menubar lost what content - and persistantly or until the compositor was restarted?
Comment 14 retired 2015-04-15 16:31:29 UTC
Sorry, I meant plasma taskbar, not menubar. It went clean during freeze. no icons, until compositor recovered.

>Could "mozilla apps" be the cause for you as well?
I will install browser I'm not fan of to see what happens. Wow, it will hit 50 this year...
Comment 15 retired 2015-04-27 16:57:46 UTC
So, I have added export KWIN_EXPLICIT_SYNC=0 to /etc/profile. It's been stable since. It was indeed caused by firefox, sometimes by plugin-container, sometimes by doing nothing. 
One common thing was firefox running in background.
Comment 16 retired 2015-08-08 12:10:17 UTC
I've tried plasma again after two months of Cinnamon usage. It is no longer happening, which is nice, KWIN_EXPLICIT_SYNC=0 is no longer needed.
Arch x86_64
Nvidia 352.30
Plasma 5.3.2