undefined | Better HN

0 pointshedora6mo ago0 comments

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.

0 comments

imiric6mo ago

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!

hedoraOP6mo ago

That’s almost certainly the problem. Play with the Linux CPU governor or (better) the package TDP (in the bios) instead.

Jnr6mo ago

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

hedoraOP6mo ago

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.

j / k navigate · click thread line to collapse

0 pointshedora6mo ago0 comments

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.

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.

0 comments

imiric6mo ago

Thanks for the suggestion!

hedoraOP6mo ago

That’s almost certainly the problem. Play with the Linux CPU governor or (better) the package TDP (in the bios) instead.

Jnr6mo ago

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

hedoraOP6mo ago

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.

j / k navigate · click thread line to collapse