Are you running multiple monitors? In either case,
have you looked at
this kernel bug report:
? It's definitely not
a localised issue if yours is the same.
On 14/7/20 10:56 am, Chris Riddoch wrote:
I believe I may be experiencing the same issue,
but I'm not certain if
it's identical. Since updating my laptop (running tumbleweed) to the
5.7.7 kernel last week with the Jul. 9 release, Xorg crashes whenever
something makes use of the radeon.
My laptop is an Asus V301L, and lspci reports the hardware:
00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT
Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller])
04:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Mars LE [Radeon HD 8530M / R5 M240] (prog-if 00 [VGA
PRIME offloading makes use of the Radeon, which I believe is a
Southern Islands OLAND chipset.
I use Plasma for my desktop. Under tumbleweed kernel 5.7.5-1.2, I
could run glxgears, firefox playing youtube videos, and factorio
acceptably well. Under 5.7.7-1.2, glxgears shows a black, unchanging
window. Running radeontop simultaneously shows that the radeon has
usage levels I'd associate with running a GL-rendering workload on it,
but nothing is sent to the display. Playing youtube videos in firefox,
loading factorio both cause Xorg to crash with SIGABRT.
It isn't happening randomly for me, it's happening specifically when
something is trying to make use of the radeon. I get kernel messages
in syslog (like "radeon 0000:04:00.0: WB enabled") whenever
I run something with the DRI_PRIME=1 environment, which I infer are
the result of some initialization sequence.
I see no errors from the kernel-level/dmesg upon Xorg crashing.
Looking through backtraces I suspect low-level drivers are responsible,
however. I'm still investigating the sequence of events, but I haven't
figured out running X under gdb yet, and it will probably involve slowly
poking at an ssh session from my phone. Not a covnenient setup
for debugging graphics-stack issues. I'll post more specifics when I
can get something useful from a backtrace.
It's been a very long time since I've built custom kernels, and I'm not
looking forward to attempting to bisect the issue, given reports that
commits simply don't compile at all. I can trigger the crashes very
I'm about to become more committed to using borg for backups prior
to every zypper dup, as it's now not possible for me to revert to a
working system. :(
On 7/10/20, Stratos Zolotas <strzol(a)gmail.com> wrote:
On Fri, Jul 10, 2020 at 2:57 PM John Janus
I'm using a dual monitor setup with one
1920x1080 monitor and one
The computer ran at least 10 hours yesterday with kernel 5.7.7
Thank you for the feedback.
Got the "bug" in 15 minutes today with 5.7.7, running for 3-4 hours
now with 5.7.5 with no issues...Bad thing is that neither upstream
they seem to have an idea about what is causing it...
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org