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.

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!

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