[PATCH] Disable panel self-refresh on AMD GPUs
KDE Linux has already done this. It works around a long-running bug in the AMD GPU driver, which I believe also affects my test laptop. Without the workaround, the system freezes and does not recover until a hard reboot. Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com> --- host/efi.nix | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/host/efi.nix b/host/efi.nix index ecedb6bea6bf29c7a7303dc9062fe12b5c7a9fbd..a832489f3816ca66c2170f0f114a4a8e3a357e32 100644 --- a/host/efi.nix +++ b/host/efi.nix @@ -35,6 +35,6 @@ runCommand "spectrum-efi" { --linux ${kernel} \ --initrd ${initramfs} \ --os-release $'NAME="Spectrum"\n' \ - --cmdline "ro intel_iommu=on roothash=$roothash" + --cmdline "ro intel_iommu=on roothash=$roothash amdgpu.dcdebugmask=0x10" '' ) (_: {}) --- base-commit: 5b3151fd08d1f1e3e166a328449fe6fe5092f316 change-id: 20260520-disable-panel-self-refresh-6c5e1dc0bab5 -- Sincerely, Demi Marie Obenour (she/her/hers)
KDE Linux has already done this. It works around a long-running bug in the AMD GPU driver, which I believe also affects my test laptop. Without the workaround, the system freezes and does not recover until a hard reboot. A potential fix has been sent upstream, but there's no guarantee it fixes the problem and it isn't in mainline yet. Once the relevant the fix included in the latest stable kernel and confirmed to work, this patch can be reverted. Link: https://invent.kde.org/kde-linux/kde-linux/-/merge_requests/431 Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/4831 Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/4643 Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/4816 Link: https://lore.kernel.org/amd-gfx/20260519220529.202096-1-sunpeng.li@amd.com/ Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com> --- Changes in v2: - Link to multiple reports of the bug. - Link to KDE Linux's choice to add amdgpu.dcdebugmask=0x10. - Link to v1: https://spectrum-os.org/lists/archives/spectrum-devel/20260520-disable-panel... --- host/efi.nix | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/host/efi.nix b/host/efi.nix index ecedb6bea6bf29c7a7303dc9062fe12b5c7a9fbd..a832489f3816ca66c2170f0f114a4a8e3a357e32 100644 --- a/host/efi.nix +++ b/host/efi.nix @@ -35,6 +35,6 @@ runCommand "spectrum-efi" { --linux ${kernel} \ --initrd ${initramfs} \ --os-release $'NAME="Spectrum"\n' \ - --cmdline "ro intel_iommu=on roothash=$roothash" + --cmdline "ro intel_iommu=on roothash=$roothash amdgpu.dcdebugmask=0x10" '' ) (_: {}) --- base-commit: 5b3151fd08d1f1e3e166a328449fe6fe5092f316 change-id: 20260520-disable-panel-self-refresh-6c5e1dc0bab5 -- Sincerely, Demi Marie Obenour (she/her/hers)
Demi Marie Obenour <demiobenour@gmail.com> writes:
KDE Linux has already done this. It works around a long-running bug in the AMD GPU driver, which I believe also affects my test laptop. Without the workaround, the system freezes and does not recover until a hard reboot.
You tested this on your test laptop and it solved the problem? Did you manually work around the card0/card1 bug? Do the proposed upstream patches also solve the problem?
On 5/21/26 08:52, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
KDE Linux has already done this. It works around a long-running bug in the AMD GPU driver, which I believe also affects my test laptop. Without the workaround, the system freezes and does not recover until a hard reboot.
You tested this on your test laptop and it solved the problem?
I didn't test it on my own hardware. After having spent so long on Cloud Hypervisor, I'm having to set myself up for Spectrum development again, and that is taking a little bit of time. However, the symptoms are identical to what many others have seen: a freeze that needs a hard reboot to recover from.
Did you manually work around the card0/card1 bug?
That bug would cause Weston to fail to start, but not to freeze once started.
Do the proposed upstream patches also solve the problem?
I do not know, but they aren't in any stable kernel release yet, and KDE decided they weren't willing to wait for them. I don't think it makes sense for Spectrum to wait, either. The bug breaks Spectrum on what I suspect is a significant amount of hardware. Panel self-refresh is a completely optional feature that only saves a small amount of power. I'm inclined to trust the KWin developers' judgement on this. If KDE Linux reverts this change, I will send a patch to revert it in Spectrum. -- Sincerely, Demi Marie Obenour (she/her/hers)
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 5/21/26 08:52, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
KDE Linux has already done this. It works around a long-running bug in the AMD GPU driver, which I believe also affects my test laptop. Without the workaround, the system freezes and does not recover until a hard reboot.
You tested this on your test laptop and it solved the problem?
I didn't test it on my own hardware. After having spent so long on Cloud Hypervisor, I'm having to set myself up for Spectrum development again, and that is taking a little bit of time.
However, the symptoms are identical to what many others have seen: a freeze that needs a hard reboot to recover from.
Did you manually work around the card0/card1 bug?
That bug would cause Weston to fail to start, but not to freeze once started.
Right, but you'd have to get past it to even observe this problem, wouldn't you? So I'm not sure anybody would actually be affected by this currently.
Do the proposed upstream patches also solve the problem?
I do not know, but they aren't in any stable kernel release yet, and KDE decided they weren't willing to wait for them. I don't think it makes sense for Spectrum to wait, either.
The bug breaks Spectrum on what I suspect is a significant amount of hardware. Panel self-refresh is a completely optional feature that only saves a small amount of power.
I'm inclined to trust the KWin developers' judgement on this. If KDE Linux reverts this change, I will send a patch to revert it in Spectrum. -- Sincerely, Demi Marie Obenour (she/her/hers)
On 5/21/26 11:50, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 5/21/26 08:52, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
KDE Linux has already done this. It works around a long-running bug in the AMD GPU driver, which I believe also affects my test laptop. Without the workaround, the system freezes and does not recover until a hard reboot.
You tested this on your test laptop and it solved the problem?
I didn't test it on my own hardware. After having spent so long on Cloud Hypervisor, I'm having to set myself up for Spectrum development again, and that is taking a little bit of time.
However, the symptoms are identical to what many others have seen: a freeze that needs a hard reboot to recover from.
Did you manually work around the card0/card1 bug?
That bug would cause Weston to fail to start, but not to freeze once started.
Right, but you'd have to get past it to even observe this problem, wouldn't you? So I'm not sure anybody would actually be affected by this currently.
This patch could still be useful once Spectrum uses COSMIC, or for anyone who has worked around the card0/card1 bug in their trees. I'll see if it fixes the problem on my system. If this does fix the problem on my system (with the workaround), I recommend applying it. Once KDE Linux stops including amdgpu.dcdebugmask=0x10, it then makes sense for Spectrum to do the same. This problem is very severe and has lasted quite a while [1]. There is also a report [2] of corruption on certain systems that needs amdgpu.dcdebugmask=0x410 to resolve. There is a patch [3] but it is not upstreamed to Linus's tree. It might be fixed by AMD moving the relevant functionality into the power module in the display controller. Presumably, this is firmware shared with Windows, which means it should be better tested. Given the long list of problems with the display controller driver [4], I suspect it is better to use the workaround for now. [1]: https://invent.kde.org/kde-linux/kde-linux/-/merge_requests/431 [2]: https://gitlab.freedesktop.org/drm/amd/-/work_items/5087 [3]: https://lore.kernel.org/amd-gfx/20260329035830.21953-1-voroninan95ton@gmail.... [4]: https://gitlab.freedesktop.org/drm/amd/-/work_items?state=opened&label_name%... -- Sincerely, Demi Marie Obenour (she/her/hers)
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 5/21/26 11:50, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 5/21/26 08:52, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
KDE Linux has already done this. It works around a long-running bug in the AMD GPU driver, which I believe also affects my test laptop. Without the workaround, the system freezes and does not recover until a hard reboot.
You tested this on your test laptop and it solved the problem?
I didn't test it on my own hardware. After having spent so long on Cloud Hypervisor, I'm having to set myself up for Spectrum development again, and that is taking a little bit of time.
However, the symptoms are identical to what many others have seen: a freeze that needs a hard reboot to recover from.
Did you manually work around the card0/card1 bug?
That bug would cause Weston to fail to start, but not to freeze once started.
Right, but you'd have to get past it to even observe this problem, wouldn't you? So I'm not sure anybody would actually be affected by this currently.
This patch could still be useful once Spectrum uses COSMIC, or for anyone who has worked around the card0/card1 bug in their trees. I'll see if it fixes the problem on my system.
If this does fix the problem on my system (with the workaround), I recommend applying it. Once KDE Linux stops including amdgpu.dcdebugmask=0x10, it then makes sense for Spectrum to do the same.
This problem is very severe and has lasted quite a while [1].
There is also a report [2] of corruption on certain systems that needs amdgpu.dcdebugmask=0x410 to resolve. There is a patch [3] but it is not upstreamed to Linus's tree. It might be fixed by AMD moving the relevant functionality into the power module in the display controller. Presumably, this is firmware shared with Windows, which means it should be better tested.
Given the long list of problems with the display controller driver [4], I suspect it is better to use the workaround for now.
[1]: https://invent.kde.org/kde-linux/kde-linux/-/merge_requests/431 [2]: https://gitlab.freedesktop.org/drm/amd/-/work_items/5087 [3]: https://lore.kernel.org/amd-gfx/20260329035830.21953-1-voroninan95ton@gmail.... [4]: https://gitlab.freedesktop.org/drm/amd/-/work_items?state=opened&label_name%...
I don't see any point in working around an issue that will likely be fixed before we make things work enough for anybody to encounter it. If it's still unfixed upstream once the card0/card1 issue is sorted, or if we discover there are systems that would have card0 and be affected by this bug, I'll consider applying it then. Otherwise it's just churn that benefits nobody.
participants (2)
-
Alyssa Ross -
Demi Marie Obenour