Bug 1399396 - Plasmashell freezes
Summary: Plasmashell freezes
Keywords:
Status: CLOSED DUPLICATE of bug 1384843
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: 25
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: PrioritizedBug
: 1294273 1409109 1410753 (view as bug list)
Depends On: 1384843
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-29 00:59 UTC by Eugene Mah
Modified: 2017-03-15 23:54 UTC (History)
60 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-12 18:25:16 UTC
Type: Bug


Attachments (Terms of Use)
backtrace of frozen plasmashell process (6.86 KB, text/plain)
2016-11-29 00:59 UTC, Eugene Mah
no flags Details
gdb backtrace on an ATI Mobility Radeon card in fedora 25 x86-64 (64.21 KB, text/plain)
2016-12-04 19:16 UTC, Shlomi Fish
no flags Details
Radeon Backtrace (58.72 KB, text/plain)
2016-12-05 18:36 UTC, Michael Davis
no flags Details
Detailed Radeon Backtrace (76.54 KB, text/plain)
2016-12-05 20:11 UTC, Michael Davis
no flags Details


Links
System ID Private Priority Status Summary Last Updated
FreeDesktop.org 99333 0 None None None 2017-01-10 12:09:07 UTC
KDE Software Compilation 373427 0 NOR RESOLVED Plasma locks up in nouveau DRI2GetBuffersWithFormat creating new windows. 2020-09-21 14:51:48 UTC
Mageia 19869 0 None None None Never
Red Hat Bugzilla 1193742 0 unspecified CLOSED Plasma5 Freezes (often due to notifications while locked), xcb/dri deadlock? 2021-02-22 00:41:40 UTC

Internal Links: 1193742

Description Eugene Mah 2016-11-29 00:59:59 UTC
Created attachment 1225536 [details]
backtrace of frozen plasmashell process

Description of problem:
At seemingly random intervals, plasmashell will completely freeze. Any applications I currently have running are still functioning, but the task bar and the desktop background is unresponsive. Any widgets on the desktop are frozen and unresponsive as well.

Killing and restarting plasmashell fixes things until it freezes again.

Version-Release number of selected component (if applicable):
plasma-workspace-5.8.4-1.fc25.x86_64

How reproducible:
Not sure how to make it reliably happen, although it often occurs when I'm mousing over icons/applications in the task bar.

Steps to Reproduce:
1. Log in to KDE 5 session
2. Do things
3. Sometimes plasmashell freezes after a few minutes, sometimes I can work for several hours with nothing happening.

Actual results:
Eventually plasmashell freezes.

Expected results:
Nothing

Additional info:
Behaviour is very similar to what was reported in bug #1294273

Comment 1 Eugene Mah 2016-11-29 01:01:22 UTC
Oh, forgot to mention that this is a fresh install of Fedora 25 KDE spin

Comment 2 Rex Dieter 2016-11-29 02:32:24 UTC
backtrace snippet:

#0  0x00007f79e8b6e00d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f79edb3ad10 in poll (__timeout=-1, __nfds=1, __fds=0x7ffd52fc90e0)
    at /usr/include/bits/poll2.h:46
#2  0x00007f79edb3ad10 in _xcb_conn_wait (c=c@entry=0x560e8cf7d310, cond=cond@entry=0x7ffd52fc9200, vector=vector@entry=0x0, count=count@entry=0x0) at xcb_conn.c:479
#3  0x00007f79edb3c7cf in wait_for_reply (c=c@entry=0x560e8cf7d310, request=request@entry=53959, e=e@entry=0x7ffd52fc92d0) at xcb_in.c:516
#4  0x00007f79edb3c941 in xcb_wait_for_reply64 (c=c@entry=0x560e8cf7d310, request=53959, e=e@entry=0x7ffd52fc92d0) at xcb_in.c:560
#5  0x00007f79edfaabd8 in _XReply (dpy=dpy@entry=0x560e8cf7bf80, rep=rep@entry=0x7ffd52fc9350, extra=extra@entry=0, discard=discard@entry=0) at xcb_io.c:596
#6  0x00007f79e6d194ba in DRI2GetBuffersWithFormat (dpy=0x560e8cf7bf80, drawable=44040261, width=width@entry=0x560e90ae8958, height=height@entry=0x560e90ae895c, attachments=0x7ffd52fc9500, count=1, outCount=0x7ffd52fc94c0) at dri2.c:491
#7  0x00007f79e6d19817 in dri2GetBuffersWithFormat (driDrawable=<optimized out>, width=0x560e90ae8958, height=0x560e90ae895c, attachments=<optimized out>, count=<optimized out>, out_count=0x7ffd52fc94c0, loaderPrivate=0x560e914bf580) at dri2_glx.c:894
#8  0x00007f7936613e98 in dri2_drawable_get_buffers (count=<synthetic pointer>, atts=0x560e9032a740, drawable=0x560e8fe4ecf0) at dri2.c:263
#9  0x00007f7936613e98 in dri2_allocate_textures (ctx=0x560e8db35710, drawable=0x560e8fe4ecf0, statts=0x560e9032a740, statts_count=2) at dri2.c:458
#10 0x00007f793660ff5c in dri_st_framebuffer_validate (stctx=<optimized out>, stfbi=<optimized out>, statts=0x560e9032a740, count=2, out=0x7ffd52fc9630)


resembles a possible video driver deadlock

Comment 3 Eugene Mah 2016-11-29 12:26:50 UTC
Hmm. Using the nouveau driver with a NVIDIA GTX 260 card. Don't remember running into this issue when I was running Fedora 24.

If there's more info I need to extract, let me know and I'll see what I can do

Comment 4 Sammy 2016-11-29 17:03:35 UTC
I am having the same problem, frequent freezes using NVIDIA Corporation GF119 [NVS 310].

KDE had problems with nouveau as reported in bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1376107

I have been using these build with some locking patches. They worked under FC24
and plasma-desktop 5.8.3, kf5-plasma 5.27.0, and of course qt5-5.6.2. So, the main
difference seems to be desktop 5.8.4 and qt5-5.7.0. Most likely a qt issue.

Comment 5 Sammy 2016-11-29 17:39:38 UTC
To clarify, I am on Fedora 25 and I have tried both mesa version, the standard
and the ones that contain locking patches. The freeze is happneing every few
minutes.

Comment 6 Phil Oester 2016-11-29 20:01:51 UTC
I've got two F25 KDE systems, but this problem only occurs on one of them.  The problematic one has Radeon HD 5000/6000/7350/8350 Series and dual monitors.  The one without an issue is using onboard Intel graphics.

Comment 7 Sammy 2016-11-29 22:36:57 UTC
Radeon is new. In the mean time I switched to propriety Nvidia drivers and the problems are gone. I noticed a f25 build for mesa 12.0.4 which has some of the
lock patches in but I doubt it will fix the problem.

Comment 8 Michael Carney 2016-11-30 00:41:10 UTC
I'm having the same issue:

F25 KDE spin + Nvidia Quadro K600 + nouveau = frequent plasma freezes.

Workaround: bounce the console between text and kdm: ctrl-alt-F3, ctrl-alt-F1

This clears the freeze without having to kill plasmashell

Comment 9 Michael Carney 2016-11-30 00:49:20 UTC
XCB messages in journal:

Nov 29 16:35:13 lucy-001 kwin_x11[8771]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 65069, resource id: 125829137, major code: 18 (ChangeProperty), minor code: 0
Nov 29 16:35:43 lucy-001 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=fprintd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Nov 29 16:37:02 lucy-001 kwin_x11[8771]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 8348, resource id: 106966343, major code: 15 (QueryTree), minor code: 0
Nov 29 16:44:51 lucy-001 kwin_x11[8771]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 33552, resource id: 32677302, major code: 3 (GetWindowAttributes), minor code: 0
Nov 29 16:44:51 lucy-001 kwin_x11[8771]: QXcbConnection: XCB error: 9 (BadDrawable), sequence: 33553, resource id: 32677302, major code: 14 (GetGeometry), minor code: 0
Nov 29 16:44:59 lucy-001 kwin_x11[8771]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 35792, resource id: 125829128, major code: 18 (ChangeProperty), minor code: 0
Nov 29 16:44:59 lucy-001 kwin_x11[8771]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 35796, resource id: 136314888, major code: 18 (ChangeProperty), minor code: 0
Nov 29 16:45:00 lucy-001 kwin_x11[8771]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 36114, resource id: 32687283, major code: 3 (GetWindowAttributes), minor code: 0
Nov 29 16:45:00 lucy-001 kwin_x11[8771]: QXcbConnection: XCB error: 9 (BadDrawable), sequence: 36115, resource id: 32687283, major code: 14 (GetGeometry), minor code: 0
Nov 29 16:45:07 lucy-001 kwin_x11[8771]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 37185, resource id: 125829128, major code: 18 (ChangeProperty), minor code: 0
Nov 29 16:45:07 lucy-001 kwin_x11[8771]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 37189, resource id: 136314888, major code: 18 (ChangeProperty), minor code: 0
Nov 29 16:45:08 lucy-001 kwin_x11[8771]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 37285, resource id: 32687336, major code: 3 (GetWindowAttributes), minor code: 0
Nov 29 16:45:08 lucy-001 kwin_x11[8771]: QXcbConnection: XCB error: 9 (BadDrawable), sequence: 37286, resource id: 32687336, major code: 14 (GetGeometry), minor code: 0
Nov 29 16:45:09 lucy-001 ksmserver[8766]: QXcbWindow: Unhandled client message: "_NET_CURRENT_DESKTOP"
Nov 29 16:45:09 lucy-001 kwin_x11[8771]: QXcbWindow: Unhandled client message: "_NET_CURRENT_DESKTOP"

Comment 10 Eugene Mah 2016-11-30 12:06:18 UTC
Also reported in #1399396

Comment 11 Neal Gompa 2016-11-30 12:17:16 UTC
This is happening to me with an AMD Radeon card (using radeon driver).

Comment 12 Neal Gompa 2016-11-30 12:17:53 UTC
It occurs to me I should note that I have three monitors.

Comment 13 Rex Dieter 2016-11-30 13:20:13 UTC
adjusting vague summary to track that this bug is specifically about plasma/nouveau deadlocks

folks with other hardware/drivers, please file separate bugs, ideally with backtraces similar to what's included initial comment and comment #3 here.  Thanks.

Comment 14 Matthias 2016-11-30 13:40:50 UTC
Is it clear that this is related to nouveau? I have seen this behavior with nouveau but also on a machine with older Intel graphics. Above it was reported with AMD hardware.

Comment 15 Rex Dieter 2016-11-30 13:48:32 UTC
original reporter uses nouveau, and the backtrace here is almost certainly specific to that driver... so yes (for now)

Comment 16 Rex Dieter 2016-11-30 13:49:06 UTC
that is, unless some amd users can provide backtraces, debugging, evidence, that the issues are indeed the same.

Comment 17 Phil Oester 2016-11-30 17:37:20 UTC
Given multiple users have indicated they are not using nouveau, I'd say that is not the common thread.  

Perhaps the common issue is multiple monitors?  I don't have this problem on my single monitor system.  Anyone else here experiencing the problem without multiple monitors?

Comment 18 Stuart Jarvis 2016-11-30 18:45:57 UTC
Possibly OT (Radeon, I don't have the debug packages installed yet, but will do)

FWIW, same symptoms on *single* monitor setup here.

Also, as per comment 8 (nouveau) Switching VTs makes plasma responsive again, with no restart

Comment 19 Michael Carney 2016-11-30 19:22:59 UTC
Single monitor here as well.

Comment 20 Matthias 2016-11-30 22:02:28 UTC
I also see this on single monitor setups. And as described, switching to console helps to unfreeze. However, after a few minutes it will freeze again.

Comment 21 michiel 2016-12-01 19:46:07 UTC
Here plasma-hell freeze at RS780L [Radeon 3000]. Console switch trick unfreezes. Both on upgraded and fresh 25. sddm startup hangs at splash screen; also here  the console switch trick works.

Did logging with 
#QT_LOGGING_RULES="* = true
#qt.* = false" plasmashell &> plasmashell.log

lots of noise but no backtraces in log nor journal

Comment 22 Scott Dowdle 2016-12-01 22:22:36 UTC
A work around... although the problem seems to come back more and more... but the work around works... until this gets fixed... you don't have to kill and restart plasmashell... you can just switch to a virtual console and back again.  So give this a try:

Alt+Control+F2 (to switch to the virtual console on tty2)
Alt+Control+F1 (to switch back to the GUI desktop)

I have the issue on a Radeon-based system.

Comment 23 Armands Liepins 2016-12-02 15:39:55 UTC
For me it started with Fedora 24 (see bug #1193742) and still happens on F25. Intel driver. Switching to vt and back unfreezes plasma. It happens also with VLC with very similar backtrace. VLC window when resizing often turns black and stops responding to keystrokes, vt trick get it back to normal.

Comment 24 Sammy 2016-12-02 16:17:26 UTC
Interesting with intel...I don't have any problem on my intel laptops. The problem for nouveau is clearly card dependent I have 4 nvidia machines, 3 of them have
the problem, all with NVS 310 and above, namely using the Nvidia 375 drivers,
but the old one with NVS300 that is limited to 340.xx drivers is working fine
with nouveau. My temporary solution was to switch to propriety drivers from rpmfusion for the three machines. No problem with these drivers. This seems to
suggest that something in nouveau is the culprit in my case unless there is a particular call from qt or plasma-shell that nouveau is failing on but nividia knows how to handle it.

Comment 25 Shlomi Fish 2016-12-04 19:16:52 UTC
Created attachment 1227943 [details]
gdb backtrace on an ATI Mobility Radeon card in fedora 25 x86-64

This is a backtrace for the plasmashell panel hangup for this machine running Fedora 25 x86-64:

<<<<<<<<<<<
I also have an Acer Aspire 5738DZG laptop with the following specs:

    Intel Pentium(R) Dual-Core CPU T4300 @ 2.10GHz. (x86-64).
    ATI Mobility Radeon™ HD 4570 (r700)
    15.6″ 3D HD LCD Screen.
    3 GB Memory
    320 GB Hard Disk Drive.
    “DVD Super Multi DL drive”
    Acer Nplify™ 802.11b/g/n.


>>>>>>>>>>>

note that I am getting similar symptoms in plasma5 on my desktop Core i3 machine with Intel i965 graphics running Mageia x86-64 v6.

Comment 26 Michael Davis 2016-12-05 18:36:44 UTC
Created attachment 1228132 [details]
Radeon Backtrace

Advanced Micro Devices, Inc. [AMD/ATI] Turks PRO [Radeon HD 7570]

Comment 27 Michael Davis 2016-12-05 18:38:17 UTC
I am also seeing this multiple times a day with Fedora 25.

Default radeon drivers with a HD7570.

Comment 28 Michael Davis 2016-12-05 20:11:50 UTC
Created attachment 1228149 [details]
Detailed Radeon Backtrace

I installed the debug libraries and it happened again. So this is a more detailed gdb backtrace.

Comment 29 Neal Gompa 2016-12-06 13:00:28 UTC
This is clearly not nouveau specific.

Comment 30 Rex Dieter 2016-12-08 15:33:31 UTC
reassigning to mesa (hopefully for some feedback/insight), mostly if the 'switching vts' workaround rings any bells.

Comment 31 LarryO 2016-12-08 16:06:41 UTC
Problem also occurs with GK107, GeForce GT 640 OEM.

Comment 32 Vitaly Zaitsev 2016-12-10 16:31:11 UTC
Same problem at NVIDIA GTX 780.

Comment 33 Raphael Groner 2016-12-10 17:03:01 UTC
Could anyone work around this issue with a dnf downgrade? If yes, what packages to downgrade?

Comment 34 Igor Gnatenko 2016-12-10 17:58:57 UTC
Would be nice if someone will report this to upstream of mesa.

Comment 35 Eugene Saenko 2016-12-11 09:00:36 UTC
> 
> Killing and restarting plasmashell fixes things until it freezes again.
> 

I use nouveau driver.

For me works unfreeze without killing plasmashell:
switch Ctrl+Alt+F2 Ctrl+Alt+F1

Comment 36 Martin Kho 2016-12-11 10:49:02 UTC
Hi

Well I've this issue with a two monitor set up and a ati radeon 'TURKS' video card. The freezes started after a xorg-server (and some friends) update (to version 1.19), see [1]. Downgrading xorg-server (and some friends) solved the issue, for me at leased.

So I doubt mesa is here the culprit.

HTH

Martin Kho

[1] Bug 1384843

Comment 37 Shlomi Fish 2016-12-12 12:08:33 UTC
Hi all!

I was asked to share this workaround:

==============

# Author Boris Shtrasman license public domain
$ cat /etc/systemd/system/unfreeze_plasma.service 
[Unit]
Description=unfreezer

[Service]
Type=oneshot
ExecStart=/bin/bash -c "(/bin/chvt 1) && (/bin/chvt 7)"

$cat etc/systemd/system/unfreeze_plasma.timer 
[Unit]
Description=Timed plasma unfreeze

[Timer]
OnUnitActiveSec=1800s
OnBootSec=1800s

[Install]
WantedBy=timers.target

# systemctl enable unfreeze_plasma.timer 
Created symlink /etc/systemd/system/timers.target.wants/unfreeze_plasma.timer → /etc/systemd/system/unfreeze_plasma.timer.

Comment 38 Eugene Saenko 2016-12-12 14:43:22 UTC
I noticed that when the plasma freezing, if there is an active GTK window (e.g firefox), this window doesn't freezes and stay active. All in this window work OK untill you don't try switch to another window or open/close window.

Comment 39 Neal Gompa 2016-12-12 20:32:42 UTC
The exception to this seems to be Google Chrome/Chromium. It freezes randomly along with Plasma Shell, though usually at differing intervals.

Comment 40 Eugene Saenko 2016-12-12 21:27:53 UTC
@ Shlomi Fish
It seems that this workaround doesn't work for me. Freezes appear, may be not so frequently.

Comment 41 Scott Baker 2016-12-12 21:32:32 UTC
Not that it seems to matter at this point, but I'll add my two cents. 

1) Radeon HD 8490 / R5 235X OEM
2) Two monitors

I've probably "ctrl + alt + f2"'d 5 times just today to get my desktop usable again. Are there any other better work arounds? Downgrading packages? Anything?

It's really disruptive to getting any work done to have to do that so frequently.

Comment 42 Michael Davis 2016-12-12 21:46:44 UTC
@Scott Baker

So far the downgrade from Bug 1384843
"sudo dnf --allowerasing --releasever=24 downgrade xorg-x11-server-Xorg"
has worked for me.

Been almost a day without a freeze.

Comment 43 Jan Simonson 2016-12-13 00:06:20 UTC
Downgrading xorg-x11-server-Xorg to F24 has fixed the problem for me too. I had frequent freezes (at least every 5 minutes) since upgrading to F25. Now there has been no freeze for several houres. This id on a HP laptop with intel graphics.

Comment 44 Rex Dieter 2016-12-13 14:01:46 UTC
OK, triaging to xorg-x11-server component (for now)

Comment 45 Raphael Groner (DAASI International) 2016-12-13 15:38:30 UTC
We could reproduce here with two fresh and updated installations of Fedora 25. A dnf downgrade xorg-x11-server to version 1.19.0-0.3 (from 1.19.0-1) fixes it without random freezes any more.

Strange observation is that the freeze hits the host as well if Fedora 25 runs inside a VirtualBox machine, with enabled 3D acceleration. The host is not Fedora based.

Comment 46 Raphael Groner (DAASI International) 2016-12-13 15:46:42 UTC
The package xorg-x11-server-Xorg is meant, of course.

Comment 47 Sammy 2016-12-13 16:02:46 UTC
On the other hand with xorg-x11-server-Xorg-1.19.0-1.fc25 but using nvidia
propriety drivers instead of mesa solves the problem as well. It sounds like
Xorg is making a bad GL call that is messing up linux drivers but is somehow
handled by the propriety ones.

Comment 48 LarryO 2016-12-13 23:19:31 UTC
I believe I've discovered a way to reproduce the symptom on-demand for those of you with more experience.  Launch Apper and select any group; you'll receive an error and the "freeze" will occur.  I recreated it 6 times in a row, the test then "failed" 3 times and then recurred.

Comment 49 Eugene Saenko 2016-12-14 06:17:57 UTC
Downgrading xorg-x11-server-Xorg to F24 doesn't help me. After downgrade occasionally appears black screen with no reaction on any mouse events or keystrokes besides Ctrl+Alt+F1. Stops even music via vlc. Ctrl+Alt+F1 returns normal work.

Comment 50 Raphael Groner (DAASI International) 2016-12-14 08:18:50 UTC
No downgrade to the package of F24 needed. Just do:

dnf downgrade xorg-x11-server-Xorg

This should install the version from F25 GA (1.19.0-0.3).

Someone has now to identify the concrete patch added between Release 0.3 and 1 that brings in those weird random freezes.

Comment 51 Martin Kho 2016-12-14 10:28:27 UTC
@Raphael: Have you FC25 running as vm's? For me, version 1.19.0-0.3 was the first that made plasmashell freeze.

Btw. I'm now using a HP laptop with intel graphics 4000 - Fedora 25 with all updates - and have never had any freezes. No external monitors connected.

Martin Kho

Comment 52 Raphael Groner (DAASI International) 2016-12-14 10:41:02 UTC
@Martin Yes, we tried also in a VM, with VirtualBox in particular. The issue in VM seems to be more related to activated 3D acceleration. I guess it's some bug in between graphics driver with direct hardware access (maybe DRI?), Mesa and Xorg.

As said, the freezes went away with Xorg 1.19.0-0.3 .

Comment 53 Martin Kho 2016-12-14 11:40:25 UTC
Sorry I mentioned the wrong version. It was 0.2 as part of update [1]


Martin Kho

[1] https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/3E3W4IKRDMVT4ADRJ3BKTI2MGXYO7VQN/

Comment 54 Rex Dieter 2016-12-14 15:07:59 UTC
nominating as PrioritizedBug

Comment 55 Armands Liepins 2016-12-14 15:58:55 UTC
(In reply to Raphael Groner (DAASI International) from comment #50)

I had freezes with xorg-x11-server-Xorg-1.19.0-0.2.20160929.fc25.i686,
then with xorg-x11-server-Xorg-1.19.0-0.3.20161026.fc25.i686
and now have with xorg-x11-server-Xorg-1.19.0-1.fc25.i686.

Ancient Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03).

It worked ok some time ago with F24, then something broke and it started to freeze, after the upgrade to F25 (fresh install) - the same.

Comment 56 michiel 2016-12-14 16:05:28 UTC
Could it have to do something with this new threaded input event processing? After unfreezing previous mouse events are processed again (a click on a folder will open it) so it seems input event processing is stopped.

Comment 57 Olivier Fourdan 2016-12-14 16:17:48 UTC
(In reply to michiel from comment #56)
> Could it have to do something with this new threaded input event processing?

Unlikely, comment 49 and comment 55 mention the same happening with F24 and Xorg 1.18.x (on F24) did not have threaded input event processing (this is new in Xorg 1.19)

Comment 58 Sammy 2016-12-14 16:46:31 UTC
Does using Xrender instead of OpenGL help?

Comment 59 Scott Dowdle 2016-12-14 16:50:24 UTC
(In reply to Sammy from comment #58)
> Does using Xrender instead of OpenGL help?

Not for me.  I have had Xrender as default on my primary work machine because the other choices were noticeably more choppy with the various desktop animations... and I still hit this bug dozens of times a day.

Comment 60 Jan Kurik 2016-12-15 10:53:33 UTC
Bug 1399396 has been agreed on the list of Prioritized bugs as it affects pretty large cross-section of our users and is also probably a candidate to a Blocker bug.

Comment 61 Ray Strode [halfline] 2016-12-16 14:16:57 UTC
does putting LIBGL_ALWAYS_SOFTWARE=y into /etc/environment work around the problem ?

Comment 62 Raphael Groner (DAASI International) 2016-12-16 14:54:07 UTC
(In reply to Ray Strode [halfline] from comment #61)
> does putting LIBGL_ALWAYS_SOFTWARE=y into /etc/environment work around the
> problem ?

We deactivate 3D hardware acceleration for the VM guest. This should have the same effect and does not show any freezes.

Comment 63 michiel 2016-12-16 15:41:07 UTC
(In reply to Ray Strode [halfline] from comment #61)
> does putting LIBGL_ALWAYS_SOFTWARE=y into /etc/environment work around the
> problem ?

Yep, that seems to solve the freeze. (Not 100% sure because I don't know how reproduce)

Comment 64 Eugene Saenko 2016-12-16 16:19:00 UTC
> does putting LIBGL_ALWAYS_SOFTWARE=y into /etc/environment work around the problem ?

In this case I have no ksensors indication in the systemtray

Comment 65 Neal Gompa 2016-12-16 17:06:14 UTC
It seems that according to this comment in the Mageia bug[1], having Xorg default to DRI 3 instead of DRI 2 might fix the issue?

At least on my system, I see that Xorg initializes the DRI2 GL provider for radeon.

[1]: https://bugs.mageia.org/show_bug.cgi?id=19869#c9

Comment 66 Dennis Kliban 2016-12-16 17:37:54 UTC
(In reply to Ray Strode [halfline] from comment #61)
> does putting LIBGL_ALWAYS_SOFTWARE=y into /etc/environment work around the
> problem ?

This seems to fix the problem for me.

Comment 67 michiel 2016-12-16 19:58:17 UTC
(In reply to Neal Gompa from comment #65)
> It seems that according to this comment in the Mageia bug[1], having Xorg
> default to DRI 3 instead of DRI 2 might fix the issue?
> 
> At least on my system, I see that Xorg initializes the DRI2 GL provider for
> radeon.
> 
> [1]: https://bugs.mageia.org/show_bug.cgi?id=19869#c9

Yes! Enabling dri3 by menas of xorg.conf will prevent freezing.

Comment 68 Colin J Thomson 2016-12-17 17:22:10 UTC
After creating a basic xorg.conf which enables DRI 3 I have had no freezes for ~36 hours where as before I could get up to 10 per day. I could never find what triggers it.

Running F25 x86_64/Nouveau, xorg-x11-server-Xorg-1.19.0-2
Not revalent to this bug but I also have the patched mesa drivers from kkofler.

Xorg.conf:

Section "Device"
        Identifier  "Videocard0"
        Driver      "nouveau"
        Option      "DRI" "3"

Xorg logs:

(**) NOUVEAU(0): Option "DRI" "3"
(**) NOUVEAU(0): Allowed maximum DRI level 3.
(II) NOUVEAU(0): [DRI2] Setup complete
(II) NOUVEAU(0): [DRI2]   DRI driver: nouveau
(II) NOUVEAU(0): [DRI2]   VDPAU driver: nouveau
(II) NOUVEAU(0): DRI3 on EXA enabled
(II) GLX: Initialized DRI2 GL provider for screen 0

Comment 69 LarryO 2016-12-17 19:40:14 UTC
I also enabled DRI3 last night and have had no "freezes" either.  Performance seems better but kwin seems unhappy but that is not directly relevant to this issue.  I noticed that the GLX drivers only initialized DRI2; is this correct or should something else be configured aside from the above section?

Comment 70 Colin J Thomson 2016-12-17 20:06:50 UTC
As far as I know that is correct. For example if you run this:

LIBGL_DEBUG=verbose vblank_mode=0 glxgears

It should report that DRI 3 is indeed being used. I am no expert on this just a user.
As for kwin I had to disable vsync in System Settings for it to behave on this box. That was sometime ago before this issue though.

Comment 71 LarryO 2016-12-17 20:24:49 UTC
glxgears does reprot DRI3.  Here is part of Xorg.0.log showing DRI3 enabled but DRI2 for FLX.
[Larry@K25 ~]$ sudo grep -E "DRI|GLX" /var/log/Xorg.0.log
[    22.009] (**) NOUVEAU(0): Option "DRI" "3"
[    22.009] (**) NOUVEAU(0): Allowed maximum DRI level 3.
[    22.009] (==) NOUVEAU(0): GLX sync to VBlank enabled.
[    22.351] (II) NOUVEAU(0): [DRI2] Setup complete
[    22.351] (II) NOUVEAU(0): [DRI2]   DRI driver: nouveau
[    22.351] (II) NOUVEAU(0): [DRI2]   VDPAU driver: nouveau
[    22.351] (II) NOUVEAU(0): DRI3 on EXA enabled
[    22.712] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[    22.712] (II) AIGLX: enabled GLX_ARB_create_context
[    22.712] (II) AIGLX: enabled GLX_ARB_create_context_profile
[    22.712] (II) AIGLX: enabled GLX_EXT_create_context_es{,2}_profile
[    22.712] (II) AIGLX: enabled GLX_INTEL_swap_event
[    22.712] (II) AIGLX: enabled GLX_SGI_swap_control
[    22.712] (II) AIGLX: enabled GLX_EXT_framebuffer_sRGB
[    22.712] (II) AIGLX: enabled GLX_ARB_fbconfig_float
[    22.712] (II) AIGLX: enabled GLX_EXT_fbconfig_packed_float
[    22.712] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
[    22.713] (II) AIGLX: Loaded and initialized nouveau
[    22.713] (II) GLX: Initialized DRI2 GL provider for screen 0

Comment 72 Domagoj 2016-12-19 11:47:57 UTC
(In reply to michiel from comment #67)
> (In reply to Neal Gompa from comment #65)
> > It seems that according to this comment in the Mageia bug[1], having Xorg
> > default to DRI 3 instead of DRI 2 might fix the issue?
> > 
> > At least on my system, I see that Xorg initializes the DRI2 GL provider for
> > radeon.
> > 
> > [1]: https://bugs.mageia.org/show_bug.cgi?id=19869#c9
> 
> Yes! Enabling dri3 by menas of xorg.conf will prevent freezing.

I apologize if I'm confusing the issue with my comment but I hope it helps.

I've had the same issues with plasma freezing very often with chrome running so I switched to the Mate desktop environment on Fedora 25 with AMD. However, the issues didn't go away. In Mate, Chrome kept freezing very often but the environment was fine and I was able to force quite the app.

After making a 20-radeon.conf file in /etc/X11/xorg.conf.d that had DRI 3 enabled:
Section "Device"
    Identifier "Radeon"
    Driver "radeon"
    Option "DRI" "3"
EndSection

The problem went away and I haven't had a single freeze ever since. I will try it on Plasma and see if it works there as well.

Comment 73 LarryO 2016-12-19 21:54:56 UTC
(In reply to Domagoj from comment #72)
> (In reply to michiel from comment #67)
> > (In reply to Neal Gompa from comment #65)
> > > It seems that according to this comment in the Mageia bug[1], having Xorg
> > > default to DRI 3 instead of DRI 2 might fix the issue?
> > > 
> > > At least on my system, I see that Xorg initializes the DRI2 GL provider for
> > > radeon.
> > > 
> > > [1]: https://bugs.mageia.org/show_bug.cgi?id=19869#c9
> > 
> > Yes! Enabling dri3 by menas of xorg.conf will prevent freezing.
> 
> I apologize if I'm confusing the issue with my comment but I hope it helps.
> 
> I've had the same issues with plasma freezing very often with chrome running
> so I switched to the Mate desktop environment on Fedora 25 with AMD.
> However, the issues didn't go away. In Mate, Chrome kept freezing very often
> but the environment was fine and I was able to force quite the app.
> 
> After making a 20-radeon.conf file in /etc/X11/xorg.conf.d that had DRI 3
> enabled:
> Section "Device"
>     Identifier "Radeon"
>     Driver "radeon"
>     Option "DRI" "3"
> EndSection
> 
> The problem went away and I haven't had a single freeze ever since. I will
> try it on Plasma and see if it works there as well.

If you don't mind, I'd likle to see the output from "sudo grep DRI2 /var/log/Xorg.0.log"

Comment 74 Domagoj 2016-12-20 01:07:38 UTC
(In reply to LarryO from comment #73)
> (In reply to Domagoj from comment #72)

> If you don't mind, I'd likle to see the output from "sudo grep DRI2
> /var/log/Xorg.0.log"

Output for "sudo grep DRI2 /var/log/Xorg.0.log"

[  8844.601] (II) RADEON(0): [DRI2] Setup complete
[  8844.601] (II) RADEON(0): [DRI2]   DRI driver: r600
[  8844.601] (II) RADEON(0): [DRI2]   VDPAU driver: r600
[  8844.618] (II) GLX: Initialized DRI2 GL provider for screen 0
[  8857.847] (II) RADEON(0): [DRI2] Setup complete
[  8857.847] (II) RADEON(0): [DRI2]   DRI driver: r600
[  8857.847] (II) RADEON(0): [DRI2]   VDPAU driver: r600
[  8857.860] (II) GLX: Initialized DRI2 GL provider for screen 0
[  8862.782] (II) RADEON(0): [DRI2] Setup complete
[  8862.782] (II) RADEON(0): [DRI2]   DRI driver: r600
[  8862.782] (II) RADEON(0): [DRI2]   VDPAU driver: r600
[  8862.796] (II) GLX: Initialized DRI2 GL provider for screen 0
[  8867.624] (II) RADEON(0): [DRI2] Setup complete
[  8867.624] (II) RADEON(0): [DRI2]   DRI driver: r600
[  8867.624] (II) RADEON(0): [DRI2]   VDPAU driver: r600
[  8867.639] (II) GLX: Initialized DRI2 GL provider for screen 0
[  8872.690] (II) RADEON(0): [DRI2] Setup complete
[  8872.690] (II) RADEON(0): [DRI2]   DRI driver: r600
[  8872.690] (II) RADEON(0): [DRI2]   VDPAU driver: r600
[  8872.703] (II) GLX: Initialized DRI2 GL provider for screen 0
[  8877.617] (II) RADEON(0): [DRI2] Setup complete
[  8877.617] (II) RADEON(0): [DRI2]   DRI driver: r600
[  8877.617] (II) RADEON(0): [DRI2]   VDPAU driver: r600
[  8877.631] (II) GLX: Initialized DRI2 GL provider for screen 0

Here's also output for "sudo grep DRI3 /var/log/Xorg.0.log"

[  8844.602] (**) RADEON(0): DRI3 enabled
[  8857.847] (**) RADEON(0): DRI3 enabled
[  8862.782] (**) RADEON(0): DRI3 enabled
[  8867.625] (**) RADEON(0): DRI3 enabled
[  8872.690] (**) RADEON(0): DRI3 enabled
[  8877.618] (**) RADEON(0): DRI3 enabled

Comment 75 LarryO 2016-12-20 10:52:51 UTC
(In reply to Domagoj from comment #74)
> (In reply to LarryO from comment #73)
> > (In reply to Domagoj from comment #72)
> 
> > If you don't mind, I'd likle to see the output from "sudo grep DRI2
> > /var/log/Xorg.0.log"
> 
> Output for "sudo grep DRI2 /var/log/Xorg.0.log"
> 
> [  8844.601] (II) RADEON(0): [DRI2] Setup complete
> [  8844.601] (II) RADEON(0): [DRI2]   DRI driver: r600
> [  8844.601] (II) RADEON(0): [DRI2]   VDPAU driver: r600
> [  8844.618] (II) GLX: Initialized DRI2 GL provider for screen 0
> [  8857.847] (II) RADEON(0): [DRI2] Setup complete
> [  8857.847] (II) RADEON(0): [DRI2]   DRI driver: r600
> [  8857.847] (II) RADEON(0): [DRI2]   VDPAU driver: r600
> [  8857.860] (II) GLX: Initialized DRI2 GL provider for screen 0
> [  8862.782] (II) RADEON(0): [DRI2] Setup complete
> [  8862.782] (II) RADEON(0): [DRI2]   DRI driver: r600
> [  8862.782] (II) RADEON(0): [DRI2]   VDPAU driver: r600
> [  8862.796] (II) GLX: Initialized DRI2 GL provider for screen 0
> [  8867.624] (II) RADEON(0): [DRI2] Setup complete
> [  8867.624] (II) RADEON(0): [DRI2]   DRI driver: r600
> [  8867.624] (II) RADEON(0): [DRI2]   VDPAU driver: r600
> [  8867.639] (II) GLX: Initialized DRI2 GL provider for screen 0
> [  8872.690] (II) RADEON(0): [DRI2] Setup complete
> [  8872.690] (II) RADEON(0): [DRI2]   DRI driver: r600
> [  8872.690] (II) RADEON(0): [DRI2]   VDPAU driver: r600
> [  8872.703] (II) GLX: Initialized DRI2 GL provider for screen 0
> [  8877.617] (II) RADEON(0): [DRI2] Setup complete
> [  8877.617] (II) RADEON(0): [DRI2]   DRI driver: r600
> [  8877.617] (II) RADEON(0): [DRI2]   VDPAU driver: r600
> [  8877.631] (II) GLX: Initialized DRI2 GL provider for screen 0
> 
> Here's also output for "sudo grep DRI3 /var/log/Xorg.0.log"
> 
> [  8844.602] (**) RADEON(0): DRI3 enabled
> [  8857.847] (**) RADEON(0): DRI3 enabled
> [  8862.782] (**) RADEON(0): DRI3 enabled
> [  8867.625] (**) RADEON(0): DRI3 enabled
> [  8872.690] (**) RADEON(0): DRI3 enabled
> [  8877.618] (**) RADEON(0): DRI3 enabled

Thanks.  So, it appears that DRI2 is included, not replaced, by DRI3.  See from ""sudo grep -E "DRI(2|3)" /var/log/Xorg.0.log"
[    24.853] (II) NOUVEAU(0): [DRI2] Setup complete
[    24.853] (II) NOUVEAU(0): [DRI2]   DRI driver: nouveau
[    24.853] (II) NOUVEAU(0): [DRI2]   VDPAU driver: nouveau
[    24.853] (II) NOUVEAU(0): DRI3 on EXA enabled
[    25.217] (II) GLX: Initialized DRI2 GL provider for screen 0

Comment 76 Terry A. Hurlbut 2016-12-20 16:36:47 UTC
I have the identical problem to this on an upgrade from F24 to F25 using dnf. I run KDE and its dependent applications.

Comment 77 James Read 2016-12-23 11:05:33 UTC
Hi folks.

4 monitors, RADEON driver here, Fedora 25. For me, Google Chrome and Plasmashell freeze. Firefox, Okular and Konsole (literally that's all I run during the day!) never freeze. 

jread@mindstorm4: grep DRI /var/log/Xorg.1.log
[  8622.082] (II) RADEON(0): [DRI2] Setup complete
[  8622.082] (II) RADEON(0): [DRI2]   DRI driver: r600
[  8622.082] (II) RADEON(0): [DRI2]   VDPAU driver: r600
[  8622.083] (==) RADEON(0): DRI3 disabled
[  8622.094] (II) GLX: Initialized DRI2 GL provider for screen 0

jread@mindstorm4: rpm -qa | grep xorg | grep server
xorg-x11-server-Xwayland-1.19.0-2.fc25.x86_64
xorg-x11-server-Xorg-1.19.0-2.fc25.x86_64
xorg-x11-server-Xvfb-1.19.0-2.fc25.x86_64
xorg-x11-server-utils-7.7-20.fc25.x86_64
xorg-x11-server-Xephyr-1.19.0-2.fc25.x86_64
xorg-x11-server-common-1.19.0-2.fc25.x86_64

At the time of window's freezing, I'm getting this in my journals;

Dec 23 10:50:14 mindstorm4.teratan.lan kwin_x11[29240]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 34720, resource id: 85983236, major code: 18 (ChangeProperty), minor code: 0
Dec 23 10:50:27 mindstorm4.teratan.lan kwin_x11[29240]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 53526, resource id: 85983236, major code: 18 (ChangeProperty), minor code: 0
Dec 23 10:50:28 mindstorm4.teratan.lan kwin_x11[29240]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 57059, resource id: 31662922, major code: 10 (UnmapWindow), minor code: 0
Dec 23 10:50:28 mindstorm4.teratan.lan kwin_x11[29240]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 57064, resource id: 31662922, major code: 4 (DestroyWindow), minor code: 0

Changing virtual terminals does "unfreeze" the window. On unfreeze, getting this in the journals;

Dec 23 10:55:06 mindstorm4.teratan.lan kwin_x11[29240]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 36010, resource id: 85983240, major code: 18 (ChangeProperty), minor code: 0
Dec 23 10:55:06 mindstorm4.teratan.lan kwin_x11[29240]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 36590, resource id: 62919790, major code: 2 (ChangeWindowAttributes), minor code: 0
Dec 23 10:55:06 mindstorm4.teratan.lan kwin_x11[29240]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 36855, resource id: 62919794, major code: 18 (ChangeProperty), minor code: 0
Dec 23 10:55:06 mindstorm4.teratan.lan vlc[28542]: QObject::~QObject: Timers cannot be stopped from another thread

The freeze seems to stop the UI being drawn and in the case of Google chrome playing music - the Music stops shortly after the window "freezes". The UI is still responsive though, I can switch tabs, and see that the titlebar of the window updates to reflect the new tab title. Nothing inside the window itself is drawn though. On switching VTs back again, on unfreezing, the UI is redrawn and audio continues playing like nothing happened! 

As a note, it lookes like I'm getting similar XCB errors between every 2-10 minutes when it doesn't seem like windows are freezing that often, so the log messages might be a red herring (not necessarily related to the freezing).

Comment 78 Rex Dieter 2016-12-29 17:25:45 UTC
*** Bug 1409109 has been marked as a duplicate of this bug. ***

Comment 79 Piotr Dobrogost 2017-01-02 10:19:03 UTC
Two systems running fully updated F25, both with nvidia cards (different models) using nouveau drivers. One (two monitors) exhibits bug but the other (three monitors) does not. Turning DRI 3 on solved the problem.

Comment 80 Karel Volný 2017-01-02 15:41:42 UTC
*** Bug 1294273 has been marked as a duplicate of this bug. ***

Comment 81 Neal Gompa 2017-01-05 02:43:08 UTC
Another potential solution that was raised in the Mageia bug report is using the modesetting driver instead of the nouveau/radeon/intel/etc. ones. This would transfer the responsibility of most of the base graphics control to the kernel. Several people have indicated this might fix the problem.

Can some folks try that and see if that solves the issue? Essentially, all you need to do is do "sudo dnf remove xorg-x11-drv-ati" (replace ati with nouveau, intel, or whatever driver you're using) and you should revert to the modesetting driver.

Comment 82 Raphael Groner 2017-01-06 08:50:16 UTC
Enabling KMS generally brings some important disadvantages ¹ to let assume it won't work for some users.

¹ https://www.osadl.org/Single-View.111+M5ec938a7b3b.0.html

Comment 83 Rex Dieter 2017-01-06 13:25:07 UTC
*** Bug 1410753 has been marked as a duplicate of this bug. ***

Comment 84 Andre Dierker 2017-01-07 08:47:16 UTC
(In reply to Domagoj from comment #72)
> (In reply to michiel from comment #67)
> I apologize if I'm confusing the issue with my comment but I hope it helps.
> 
> I've had the same issues with plasma freezing very often with chrome running
> so I switched to the Mate desktop environment on Fedora 25 with AMD.
> However, the issues didn't go away. In Mate, Chrome kept freezing very often
> but the environment was fine and I was able to force quite the app.
> 
> After making a 20-radeon.conf file in /etc/X11/xorg.conf.d that had DRI 3
> enabled:
> Section "Device"
>     Identifier "Radeon"
>     Driver "radeon"
>     Option "DRI" "3"
> EndSection
> 
> The problem went away and I haven't had a single freeze ever since. I will
> try it on Plasma and see if it works there as well.

My system is now working without problems with this.
ATI graphics and two screens. Are some logs or additional iformations needed?

Comment 85 Eugene Saenko 2017-01-07 10:52:04 UTC
(In reply to Domagoj from comment #72)
> Section "Device"
>     Identifier "Radeon"
>     Driver "radeon"
>     Option "DRI" "3"
> EndSection
> 
> The problem went away and I haven't had a single freeze ever since. I will
> try it on Plasma and see if it works there as well.

I created 00-nvidia.conf:
Section "Device"
    Identifier "Nvidia"
    Driver "nouveau"
    Option "DRI" "3"
EndSection

It works for me. The problem disappeared.

Comment 86 Robert G. Werner 2017-01-07 21:09:47 UTC
I'm running an AMD/ATI Radeon HD 6750:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Juniper PRO [Radeon HD 6750]


added the 20-radion.conf file as suggested in comment 67 and restarting X,  I haven't experienced any freezes in the last 20 hours.

I haven't been using this system as hard over the weekend but I'll update if the bug reappears.

Note,  this is the only change I made.

Comment 87 Raphael Groner 2017-01-08 09:29:37 UTC
Maybe a regression of bug #1193742 ?

I found some more explanation about possible reasons:
https://forum.kde.org/viewtopic.php?f=289&t=124690

Comment 88 Olivier Fourdan 2017-01-10 07:53:15 UTC
Keith posted a patch here: https://patchwork.freedesktop.org/series/17732/

Comment 89 Rex Dieter 2017-01-11 15:30:09 UTC
FYI, feedback on
https://bugs.mageia.org/show_bug.cgi?id=19869
https://bugs.freedesktop.org/show_bug.cgi?id=99333

includes several positive confirmations that the patch works as advertised.

Comment 90 Raphael Groner (DAASI International) 2017-01-11 15:45:59 UTC
+1

Please include the patch also in Fedora.

Comment 91 Matthew Miller 2017-01-11 17:42:20 UTC
(In reply to Raphael Groner (DAASI International) from comment #90)
> +1
> 
> Please include the patch also in Fedora.

Are you saying you've tested it and it works?

Comment 92 Raphael Groner 2017-01-11 17:57:28 UTC
(In reply to Matthew Miller from comment #91)
> (In reply to Raphael Groner (DAASI International) from comment #90)
> > +1
> > 
> > Please include the patch also in Fedora.
> 
> Are you saying you've tested it and it works?

When there's an official update candidate available for Fedora, we can test and give feedback and karma. Fun fact aside: I'm the only one in the company without freezes in daily work besides other collegues running all the time into freezes. So someone could assume the random freezes depend not only on the installed graphics but also the custom configuration of Plasma (desktop effects etc.) could get in the game.

Comment 93 Olivier Fourdan 2017-01-11 18:28:38 UTC
Note: there is already a new revision on the patch mentioned in comment 88

Comment 94 Jason Tibbitts 2017-01-11 23:08:03 UTC
I believe the second revision of that patch is in the newly-released (upstream) xorg-server 1.19.1.

ajax did merge that into F25 git earlier today, did a build and issued this update not very long ago: https://bodhi.fedoraproject.org/updates/FEDORA-2017-4e17feecd9

So, either download the packages from that update and try them, or wait a bit until it's pushed to testing and then get the packages that way.

Comment 95 Jason Tibbitts 2017-01-11 23:12:40 UTC
This is the bit from the xorg-server 1.19.1 release notes:

Keith Packard (1):
      AttendClient of grab-pervious client must queue to saved_ready_clients [v2]

Also, 1.19.1 isn't even 90 minutes old as I type this, so thanks to ajax for moving quickly to get it into Fedora.

Comment 96 Jason Tibbitts 2017-01-12 18:25:16 UTC
This one came first, but 1384843 is what was mentioned in the xorg update (which is already on its way to stable), so I'll close this one as a dup.

*** This bug has been marked as a duplicate of bug 1384843 ***

Comment 97 Raphael Groner (DAASI International) 2017-01-13 08:25:26 UTC
This bug is indeed fixed with the applied update mentioned in comment #94. We don't see any freezes. Thanks!


Note You need to log in before you can comment on or make changes to this bug.