Summary: | kwin crahed after waking up from suspend-to-RAM | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Arne Henningsen <arne.henningsen> |
Component: | scene-opengl | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED WORKSFORME | ||
Severity: | crash | CC: | davidsboogs, jessetalavera, kysstfafm |
Priority: | NOR | Keywords: | drkonqi |
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
See Also: |
https://bugs.kde.org/show_bug.cgi?id=345191 https://bugs.kde.org/show_bug.cgi?id=350872 |
||
Latest Commit: | Version Fixed In: | ||
Attachments: | Output of "glxinfo" |
Description
Arne Henningsen
2015-06-08 08:57:41 UTC
can you please attach the output of "glxinfo" Created attachment 93082 [details]
Output of "glxinfo"
generated with 'glxinfo > glxinfo.txt'
Thanks, just as expected. ------------------------------------ OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: Quadro 2000M/PCIe/SSE2 OpenGL core profile version string: 4.4.0 NVIDIA 346.59 OpenGL core profile shading language version string: 4.40 NVIDIA via Cg compiler OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: ------------------------------------------------------------------------ This *might* be worked around, see bug #344326 - it vastly depends when kwin crashes here. May just as well be a related problem in the nvidia driver (or it's usage by kwin, we don't know why datamoving between memories by the driver is wonky) Unfortunately, the work-around with "Alt+Shift+F12" as suggested in bug #344326 does not work for me. Perhaps, it does not work, because my screen is locked so that "Alt+Shift+F12" is blocked by the lock screen (while "Ctrl-Alt-FX", with X=1,...,7 is not blocked by the lock screen). Yes. Possible functional workarounds are a) suspending the compositor *before* suspending to ram b) the patch that resets the VBOs on memory transfer (for KWin 5.4) ==> the interesting question here is whether resetting VBOs "in time" prevents the crashes as well (or the broken memory transfer randomly causes crash and corruption, depending on the nature of the invalid access) *** Bug 352423 has been marked as a duplicate of this bug. *** *** Bug 359374 has been marked as a duplicate of this bug. *** *** Bug 361609 has been marked as a duplicate of this bug. *** The latest NVIDIA driver has an extension to report about this situation: https://www.opengl.org/registry/specs/NV/robustness_video_memory_purge.txt Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone! Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |