Bug 1030042

Summary:	Frozen screen with Chrome/Chromium - intel graphics, opengl compositing
Product:	[openSUSE] openSUSE Distribution	Reporter:	Mikhail Ramendik <mr>
Component:	KDE Workspace (Plasma)	Assignee:	E-Mail List <opensuse-kde-bugs>
Status:	RESOLVED WONTFIX	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P3 - Medium	CC:	mr, msrb, mstaudt, suse
Version:	Leap 42.2	Flags:	sndirsch: needinfo? (mr)
Target Milestone:	---
Hardware:	x86-64
OS:	openSUSE 42.2
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	/var/log/Xorg.0.log

Description Mikhail Ramendik 2017-03-20 02:29:04 UTC

After an upgrade from 42.1 to 42.2, freezes appeared once every few hours. Chrome or Chromium is always active during the freeze. Intel graphics (Ivy Bridge on my case) is used.

During teh freeze the graphical screen does not update, except that the mouse pointer continues to move. Ctrl-Alt-F1 switches to text console, then Ctrl-Alt-F7 brings back the frozen graphical screen. Pressing Ctrl-Alt-Backspace restarts X, leading to unfreezing.

No messages indicating a cause were found in /var/log/Xorg.log

When one switches compositing from OpenGL to XRender, freezes no longer occur.

The issue was experienced by a few embers of the OpenSuSe mailing list.

Comment 1 Stefan Dirsch 2017-03-20 08:44:15 UTC

*** Bug 1030043 has been marked as a duplicate of this bug. ***

Comment 2 Jan Ritzerfeld 2017-03-20 19:50:06 UTC

I can confirm this on Sandy Bridge. Mouse still moves, can switch to vt1 and restarting X unfreezes it. And since switching to XRender instead of OpenGL there have been no freezes anymore.

Comment 3 Max Staudt 2017-03-21 10:32:08 UTC

What DDX are you using?
Can you please attach /var/log/Xorg.0.log after the freeze and before restarting X?

Comment 4 Mikhail Ramendik 2017-03-21 11:04:28 UTC

Not sure what a DDX is, sorry. The driver is intel. 

There were no messages in the Xorg log at the time of the freeze except the ones about switching to the VT1, which I used to view it. I will try to reproduce the freeze and attach the entire file.

Comment 5 Max Staudt 2017-03-21 11:10:56 UTC

This may be related to boo#1013550 - when your GUI freezes, can you please capture the output of the command suggested in that bug's comment 17?

  gdb -p $(pidof plasmashell) -ex "thread apply all bt" -ex "q"

Yes, the Xorg log would be very helpful.

Comment 6 Max Staudt 2017-03-21 11:28:51 UTC

Since this is probably a bug in Plasma, I'm reassigning this to the KDE team.

Comment 7 Jan Ritzerfeld 2017-03-21 19:00:08 UTC

Created attachment 718214 [details]
/var/log/Xorg.0.log

Comment 8 Jan Ritzerfeld 2017-03-21 19:00:32 UTC

(In reply to Max Staudt from comment #6)
> Since this is probably a bug in Plasma, I'm reassigning this to the KDE team.

I do not think so, even killing plasmashell does not help.

Comment 9 Max Staudt 2017-03-22 09:30:06 UTC

Thanks for the log!

From it I can see that you're running the Intel DDX on an Ivy Bridge machine. The DDX is the 2D graphics driver in Xorg, and it's usually hardware specific.

Could you please

  zypper remove xf86-video-intel

and see how you fare with the generic "modesetting" DDX that will then be used automatically? We've seen quite a few problems with the Intel driver, though this may well be a different issue...

Comment 10 Max Staudt 2017-03-22 09:38:09 UTC

Also, do you have a way to reproduce this? I would like to debug the system when it's in the frozen state, but I can't do that if I don't know how to lock it up :/

Comment 11 Michal Srb 2017-03-28 11:18:30 UTC

I have observed likely the same issue on friend's laptop after upgrading to 42.2. The whole screen appears frozen, only mouse cursor moves. It was triggered in few minutes of playing a fullscreen game.

It was caused by kwin (compositor) being stuck waiting for response from X server to a DRI2GetBuffersWithFormat request. Kwin was trying to render the windows using opengl and the DRI2GetBuffersWithFormat request was made from somewhere deep inside Mesa.

I analyzed it briefly and X server seemed fine, no threads stuck, responding fine to other X clients, nothing in log. There was nothing in kernel log either.

(In reply to Mikhail Ramendik from comment #0)
> When one switches compositing from OpenGL to XRender, freezes no longer
> occur.

I used this as workaround as well and no longer pursued it. I can get the system again and collect backtrace or other information if needed.

Google search suggested that it may be some race condition in kwin or xcb. The fact that it happens sooner when the system is busy and screen repaints often would support that.

Comment 12 Tomáš Chvátal 2018-04-17 14:06:08 UTC

This is automated batch bugzilla cleanup.

The openSUSE 42.2 changed to end-of-life (EOL [1]) status. As such
it is no longer maintained, which means that it will not receive any
further security or bug fix updates.
As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
openSUSE, or you can still observe it under openSUSE Leap 15.0, please
feel free to reopen this bug against that version (see the "Version"
component in the bug fields), or alternatively open
a new ticket.

Thank you for reporting this bug and we are sorry it could not be fixed
during the lifetime of the release.

[1] https://en.opensuse.org/Lifetime