Commen=
t # 16
on bug 98520<=
/a>
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 somet=
imes
the complete system locks up ( everything frozen, except for the mouse poin=
ter
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 follow=
ing
a reboot ( after 5 or 6 times in a row I usually give up and switch to anot=
her
machine ).=20
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.