Hello,
I am reporting this to the regressions mailing list since it has popped up in the [Arch Linux Bugtracker][0]. It was also [already reported][1] to the relevant DRM subsystem, but is not tracked here yet.
The issue has been bisected to the following commit by someone on Gitlab:
a6ff969fe9cb ("drm/amdgpu: fix visible VRAM handling during faults")
The DRM maintainers have said that this could be something that just worked by chance in the past:
[Comment 1][2]
Christian König (@ckoenig) Mhm, no idea of hand. But it could be that this is actually an intended result.
Previously we didn't correctly checked if the requirements of an application regarding CPU accessible VRAM were meet. Now we return an error if things potentially won't work instead of crashing later on.
Can you provide the output of 'sudo cat /sys/kernel/debug/dri/0/amdgpu_vram_mm' just before running the game?
[Comment 2][3]
Damian Marcin Szymański (@AngryPenguinPL): @superm1 @ckoenig If you can't fix it before stable 6.9 can we get it reverted for now?
Christian König (@ckoenig): @AngryPenguinPL no, this is an important bug fix which even needs to be backported to older kernels.
All in all this seems to be a rather tricky situation (especially judging if this is actually a regression or not), so maybe getting some input from the stable or regression team on how to handle this well would be good!
(I'll add that I can give no direct input on the issue itself, see this as a forward / cc type of Email.)
Cheers, Chris
[0]: https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/47 [1]: https://gitlab.freedesktop.org/drm/amd/-/issues/3343 [2]: https://gitlab.freedesktop.org/drm/amd/-/issues/3343#note_2389471 [3]: https://gitlab.freedesktop.org/drm/amd/-/issues/3343#note_2400933
#regzbot introduced: a6ff969fe9cb #regzbot link: https://gitlab.freedesktop.org/drm/amd/-/issues/3343 #regzbot title: drm/amdgpu: Games crash if above 4g decoding/resize bar is disabled or not supported
Hi Christian,
most likely Michel just pointed out the right solution.
There is an off by one in the bug fix, which might cause the issue.
We are still testing, but so far it looks good.
Regards, Christian.
Am 08.05.24 um 12:36 schrieb Christian Heusel:
Hello,
I am reporting this to the regressions mailing list since it has popped up in the [Arch Linux Bugtracker][0]. It was also [already reported][1] to the relevant DRM subsystem, but is not tracked here yet.
The issue has been bisected to the following commit by someone on Gitlab:
a6ff969fe9cb ("drm/amdgpu: fix visible VRAM handling during faults")
The DRM maintainers have said that this could be something that just worked by chance in the past:
[Comment 1][2]
Christian König (@ckoenig) Mhm, no idea of hand. But it could be that this is actually an intended result.
Previously we didn't correctly checked if the requirements of an application regarding CPU accessible VRAM were meet. Now we return an error if things potentially won't work instead of crashing later on.
Can you provide the output of 'sudo cat /sys/kernel/debug/dri/0/amdgpu_vram_mm' just before running the game?
[Comment 2][3]
Damian Marcin Szymański (@AngryPenguinPL): @superm1 @ckoenig If you can't fix it before stable 6.9 can we get it reverted for now?
Christian König (@ckoenig): @AngryPenguinPL no, this is an important bug fix which even needs to be backported to older kernels.
All in all this seems to be a rather tricky situation (especially judging if this is actually a regression or not), so maybe getting some input from the stable or regression team on how to handle this well would be good!
(I'll add that I can give no direct input on the issue itself, see this as a forward / cc type of Email.)
Cheers, Chris
#regzbot introduced: a6ff969fe9cb #regzbot link: https://gitlab.freedesktop.org/drm/amd/-/issues/3343 #regzbot title: drm/amdgpu: Games crash if above 4g decoding/resize bar is disabled or not supported
On 24/05/08 01:01PM, Christian König wrote:
Hi Christian,
Hey Christian,
most likely Michel just pointed out the right solution.
There is an off by one in the bug fix, which might cause the issue.
Awesome, I think I was just missing out the relevant mail on another list!
The underlying issue being fixed is of course the easiest solution to this situation, to me it was looking like it was unclear on how to proceed.
We are still testing, but so far it looks good.
Regards, Christian.
Regards, Christian
On 24/05/08 01:01PM, Christian König wrote:
Hi Christian,
Hey Christian,
most likely Michel just pointed out the right solution.
There is an off by one in the bug fix, which might cause the issue. We are still testing, but so far it looks good.
I have applied both patches and one of the reporting users says the problem is fixed for them: https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/47#...
Regards, Christian.
Cheers, Christian
On 08.05.24 12:36, Christian Heusel wrote:
I am reporting this to the regressions mailing list since it has popped up in the [Arch Linux Bugtracker][0]. It was also [already reported][1] to the relevant DRM subsystem, but is not tracked here yet.
Thx for that!
The issue has been bisected to the following commit by someone on Gitlab:
a6ff969fe9cb ("drm/amdgpu: fix visible VRAM handling during faults")
The DRM maintainers have said that this could be something that just worked by chance in the past:
Well, that "worked by chance" itself it not much relevant when it comes to the "no regressions" rule: in such a case the culprit is normally reverted if the issue can't be fixed in some other way.
That being said:
[Comment 1][2]
Christian König (@ckoenig) Mhm, no idea of hand. But it could be that this is actually an intended result.
Previously we didn't correctly checked if the requirements of an application regarding CPU accessible VRAM were meet. Now we return an error if things potentially won't work instead of crashing later on.
Can you provide the output of 'sudo cat /sys/kernel/debug/dri/0/amdgpu_vram_mm' just before running the game?
[Comment 2][3]
Damian Marcin Szymański (@AngryPenguinPL): @superm1 @ckoenig If you can't fix it before stable 6.9 can we get it reverted for now?
Christian König (@ckoenig): @AngryPenguinPL no, this is an important bug fix which even needs to be backported to older kernels.
This sounds like it reverting might be a really bad idea for security reasons. Christian, is that right?
In that case it's likely something we should simply tell Linus about, as he's the one doing the judgement calls here -- and also the one that maybe should mention this problem in the next release announcement, if the commit remains.
Ciao, Thorsten
All in all this seems to be a rather tricky situation (especially judging if this is actually a regression or not), so maybe getting some input from the stable or regression team on how to handle this well would be good!
(I'll add that I can give no direct input on the issue itself, see this as a forward / cc type of Email.)
Cheers, Chris
#regzbot introduced: a6ff969fe9cb #regzbot link: https://gitlab.freedesktop.org/drm/amd/-/issues/3343 #regzbot title: drm/amdgpu: Games crash if above 4g decoding/resize bar is disabled or not supported
linux-stable-mirror@lists.linaro.org