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 controller]) 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, and 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 many commits simply don't compile at all. I can trigger the crashes very reliably. 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@gmail.com> wrote:
On Fri, Jul 10, 2020 at 2:57 PM John Janus <mail@johnzone.org> wrote:
I'm using a dual monitor setup with one 1920x1080 monitor and one 1680x1050 monitor. 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@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Chris Riddoch http://www.syntacticsugar.org/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org