Comment # 16
on bug 98520
from Filip
Another confirmation. In my case it's usually trigered by the browsers ( FF, Chrome, Pale Moon ) when HW accelleration is enabled. In FF/Pale Moon there's no obvious cause, while in Chrome it's usually the scrolling which triggers the freeze. Gaming wise, while I don't play much at all, I did test SuperTux Kart. In both cases freezing is completelly random, eg. no specific website, or specific location/track in STK can be isolated as the trigger. Also, sometimes I just get the application in question to freeze, and sometimes the complete system locks up ( everything frozen, except for the mouse pointer which can be moved ). Again, both are random, with the only difference being that if DRI3 is used, the complete lockup seems to happen more often than the app-only freeze. Frequency: Either stable for a single day at max, or freeze occurs back-to-back following a reboot ( after 5 or 6 times in a row I usually give up and switch to another machine ). Other details: - Machine can be accessed through SSH, and essentialy runs ( eg. Audaciuos still plays ). - X cannot be killed/restarted - Nothing in dmesg/Xorg.log/syslog etc nor in applications ( FF, STK... ) stdout - Kernel makes no difference as it seems, 4.8.x -- 4.9.0, debian pkg or self-compiled vanilla. System: - XFX RX460 4GB - Debian Stretch ( testing ) - Mesa 13.02, Gallium 0.4, DRM 3.8.0, LLVM 3.9.1, Linux 4.9 - Xorg 1.19 - XFCE 4.12 ( xfwm4 from git, with OpenGL compositing enabled ) I'll test the 4.7 kernel, and ( if I manage to roll back to ) older Mesa versions in the following days and report back.
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
