> You don't describe the problems with anywhere near enough detail to guess at what the underlying issue might be.
That's because this is the HN comment section, not the f.d.o bug tracker.
Since you seem to care, what I'm seeing is likely #2220, though the real problem for me is that dmesg output is not particularly helpful on its own and it's the entire desktop that crashes (as opposed to a single application that you could set Mesa/amdgpu debug flags on.) The fact that it "only" crashes about once per week complicates things further; aimlessly enabling debug options would probably result in getting buried in logs.
[drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout, signaled seq=24191109, emitted seq=24191111
[drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process pid 0 thread pid 0
This is really kind of a debugging worst case. There's pretty much no useful information here.
Thanks but I wasn't asking for suggestions, forcing to a high power mode is not helpful on a laptop, and various different values for ppfeaturemask have been discussed in the fd.o bug (none of which helped tackle the issue).
I don't expect it to be the cause, but who knows: does your GPU happen to be sitted in the bottom-most PCIe slot of the motherboard ? I encountered weird stuff with the PCIe lines connected to the motherboard chipset (instead of those connected directly to the CPU) on several B550. Some PCIe packets would apparently be garbled/lost when under load, resulting in the driver for the associated peripheral timing out.
That's because this is the HN comment section, not the f.d.o bug tracker.
Since you seem to care, what I'm seeing is likely #2220, though the real problem for me is that dmesg output is not particularly helpful on its own and it's the entire desktop that crashes (as opposed to a single application that you could set Mesa/amdgpu debug flags on.) The fact that it "only" crashes about once per week complicates things further; aimlessly enabling debug options would probably result in getting buried in logs.
This is really kind of a debugging worst case. There's pretty much no useful information here.