4 ms·

> But I am stupid enough to use an nvidia card, which means that I have no Wayland. I am eating shit due to the drivers every few months. Funny you would say t

> But I am stupid enough to use an nvidia card, which means that I have no Wayland. I am eating shit due to the drivers every few months. Funny you would say this; I'm on AMD (Ryzen 6950HS IGD) and I'm eating shit due to the (FOSS) drivers every few days… to be fair I have two choices of distinct shit with X11 and Wayland, but neither is actually stable. And none of this affects gaming, just the desktop in general :/. The RX 6950 in the desktop is in fact working without issues (same driver stack). I suspect it's some memory management problem with the CPU/GPU sharing on the 6950HS. But I have no idea how to track it down… That said, FOSS GPU support has come a long way.

mjevans 3y ago
Laptop APU https://www.amd.com/en/products/apu/amd-ryzen-9-pro-6950hs https://www.amd.com/en/products/apu/amd-ryzen-9-pro-6950hs You don't describe the problems with anywhere near enough detail to guess at what the underlying issue might be. https://wiki.archlinux.org/title/AMDGPU https://wiki.archlinux.org/title/AMDGPU << Has a troubleshooting section that might help.
- eqvinox 3y ago
  > 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.
  - 29athrowaway 3y ago
    echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level Or try setting the kernel boot parameter amdgpu.ppfeaturemask=0xfffd3fff
    - eqvinox 3y ago
      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).
  - asksomeoneelse 3y ago
    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.
    - eqvinox 3y ago
      This is an APU in a laptop ("Ryzen 6950HS IGD")

mjevans 3y ago

Laptop APU https://www.amd.com/en/products/apu/amd-ryzen-9-pro-6950hs https://www.amd.com/en/products/apu/amd-ryzen-9-pro-6950hs You don't describe the problems with anywhere near enough detail to guess at what the underlying issue might be. https://wiki.archlinux.org/title/AMDGPU https://wiki.archlinux.org/title/AMDGPU << Has a troubleshooting section that might help.

eqvinox 3y ago
> 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.
- 29athrowaway 3y ago
  echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level Or try setting the kernel boot parameter amdgpu.ppfeaturemask=0xfffd3fff
  - eqvinox 3y ago
    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).
- asksomeoneelse 3y ago
  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.
  - eqvinox 3y ago
    This is an APU in a laptop ("Ryzen 6950HS IGD")