I've had the same experience with an 8600G on Linux. Very frequent graphics driver crashes and KDE/Wayland freezes, on old and new kernels alike. I've been submitting error reports for months, and the issues still persist. The RAM passes MemTest, and the system otherwise works fine, but the graphics issues are very annoying. It's not like I'm gaming or doing anything intensive either; it happens during plain desktop usage.

Yet I also use a 7840U in a gaming handheld running Windows, and haven't had any issues there at all. So I think this is related to AMD Linux drivers and/or Wayland. In contrast, my old laptop with an NVIDIA GPU and Xorg has given me zero issues for about a decade now.

So I've decided to just avoid AMD on Linux on my next machine. Intel's upcoming Panther Lake and Nova Lake CPUs seem promising, and their integrated graphics have consistently been improving. I don't think AMD's dominance will continue for much longer.

▲

hedora 4 days ago | parent [-]

Check dmesg after the driver crashes and restarts. If the crash is something about a ringbuffer timeout, use dmidecode to see what the ram is actually clocked at.

Make sure it matches the min of the actual spec of the ram that you bought and what the CPU can do.

I used to get crashes like you are describing on a similar machine. The crashes are in the GPU firmware, making debugging a bit of a crap shoot. If you can run windows with the crashing workload on it, you’ll probably find it crashes the same ways as Linux.

For me, it was a bios bug that underclocked the ram. Memory tests, etc passed.

I suspect there are hard performance deadlines in the GPU stack, and the underclocked memory was causing it to miss them, and assume a hang.

If the ram frequency looks OK, check all the hardware configuration knobs you can think of. Something probably auto-detected wrong.

▲

imiric 4 days ago | parent | next [-]

Hhmm I did underclock the RAM to 4800 MHz, since running it at the stock 6400 MHz would overheat the system (it's a mini PC) and cause artifacting. And, practically, I don't need higher frequencies, since I'm using the machine as an HTPC and for casual desktop use. In fact, from what I've read, high frequencies can introduce stability issues on these APUs, which is exactly what I'm trying to avoid.

But I'll play around with this and the timings, and check if there's a BIOS update that addresses this. Though I still think that AMD's drivers and firmware should be robust enough to support any RAM configuration (within reason), so it would be a problem for them to resolve regardless.

Thanks for the suggestion!

	▲	hedora 2 days ago \| parent [-]
		That’s almost certainly the problem. Play with the Linux CPU governor or (better) the package TDP (in the bios) instead.

▲

Jnr 4 days ago | parent | prev [-]

Initially I also tried debugging, writing reports, etc. Some 8 years later I have given up and just live with the occasional crashes.

	▲	hedora 2 days ago \| parent [-]
		I found a workload that reliably crashed. (Recently released graphics-intensive steam demos that deterministically died in under 180 seconds). That gave me solid ground for debugging.