Bug 1399396

Oh, forgot to mention that this is a fresh install of Fedora 25 KDE spin

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

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

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.

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.

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.

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.

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

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"

Also reported in #1399396

This is happening to me with an AMD Radeon card (using radeon driver).

It occurs to me I should note that I have three monitors.

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.

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.

original reporter uses nouveau, and the backtrace here is almost certainly specific to that driver... so yes (for now)

that is, unless some amd users can provide backtraces, debugging, evidence, that the issues are indeed the same.

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?

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

Single monitor here as well.

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.

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

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.

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.

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.

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.

Created attachment 1228132 [details]
Radeon Backtrace

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

I am also seeing this multiple times a day with Fedora 25.

Default radeon drivers with a HD7570.

Created attachment 1228149 [details]
Detailed Radeon Backtrace

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

This is clearly not nouveau specific.

reassigning to mesa (hopefully for some feedback/insight), mostly if the 'switching vts' workaround rings any bells.

Problem also occurs with GK107, GeForce GT 640 OEM.

Same problem at NVIDIA GTX 780.

Could anyone work around this issue with a dnf downgrade? If yes, what packages to downgrade?

Would be nice if someone will report this to upstream of mesa.

> 
> 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

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

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.

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.

The exception to this seems to be Google Chrome/Chromium. It freezes randomly along with Plasma Shell, though usually at differing intervals.

@ Shlomi Fish
It seems that this workaround doesn't work for me. Freezes appear, may be not so frequently.

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.

@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.

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.

OK, triaging to xorg-x11-server component (for now)

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.

The package xorg-x11-server-Xorg is meant, of course.

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.

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.

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.

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.

@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

@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 .

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/

nominating as PrioritizedBug

(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.

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.

(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)

Does using Xrender instead of OpenGL help?

(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.

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.

does putting LIBGL_ALWAYS_SOFTWARE=y into /etc/environment work around the problem ?

(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.

(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)

> does putting LIBGL_ALWAYS_SOFTWARE=y into /etc/environment work around the problem ?

In this case I have no ksensors indication in the systemtray

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

(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.

(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.

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

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?

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.

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

(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.

(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"

(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

(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

I have the identical problem to this on an upgrade from F24 to F25 using dnf. I run KDE and its dependent applications.

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).

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

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.

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

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.

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

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

(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?

(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.

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.

Maybe a regression of bug #1193742 ?

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

Keith posted a patch here: https://patchwork.freedesktop.org/series/17732/

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.

+1

Please include the patch also in Fedora.

(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?

(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.

Note: there is already a new revision on the patch mentioned in comment 88

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.

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.

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 ***

This bug is indeed fixed with the applied update mentioned in comment #94. We don't see any freezes. Thanks!