[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250830174810.GAaLM5WkiFc2BtQ6kW@fat_crate.local>
Date: Sat, 30 Aug 2025 19:48:10 +0200
From: Borislav Petkov <bp@...en8.de>
To: Alex Deucher <alexdeucher@...il.com>
Cc: amd-gfx@...ts.freedesktop.org, Alex Deucher <alexander.deucher@....com>,
Christian König <christian.koenig@....com>,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource
seems too big for the bo
On Sat, Aug 30, 2025 at 12:30:09PM -0400, Alex Deucher wrote:
> Yes, I agree these should be warn_once(). If you send a patch I'll
> apply it, otherwise, I'll take a look next week.
See below. I tried to explain the whole situation as good as I could.
> For some background, older GPUs did not support memory protection, so the
> kernel driver validates all of the command submissions (CS) from userspace
> to make sure the commands would not access any memory they shouldn't. In
> your case it's a vertex buffer object (VBO) which contains vertex data for
> the 3D engine on the GPU. So newer mesa code is sending a command
> submission with an invalid vbo size. As such the kernel driver rejects the
> command submission. This may result in subtle rendering issues as the
> invalid command submission does not get sent to the hardware.
Very nice, thanks! I've added it to the commit message.
> I would suggest filing a mesa bug report:
> https://gitlab.freedesktop.org/mesa/mesa/-/issues/
Right, I'd love to except that's my main workstation and I don't love
testing/debugging kernels on it. The thing must JustWork(tm).
I'll try to repro on some of my other boxes and report it then.
Thanks Alex!
---
From: "Borislav Petkov (AMD)" <bp@...en8.de>
Date: Sat, 30 Aug 2025 19:24:28 +0200
Subject: [PATCH] drm/radeon/evergreen_cs: Make the VBO size mismatch message a once-type
With newer MESA (version 9.0.2 in Debian), the message
[54588.405160] evergreen_packet3_check: 32 callbacks suppressed
[54588.405166] radeon 0000:1d:00.0: vbo resource seems too big for the bo
[54588.418034] radeon 0000:1d:00.0: vbo resource seems too big for the bo
[54588.418037] radeon 0000:1d:00.0: vbo resource seems too big for the bo
...
floods dmesg and the ratelimiting doesn't help a whole lot. The user
can't really do anything about it so make it a once message.
Some background info from Alex:
"[O]lder GPUs did not support memory protection, so the kernel driver
validates all of the command submissions (CS) from userspace to make
sure the commands would not access any memory they shouldn't.
In your case it's a vertex buffer object (VBO) which contains vertex
data for the 3D engine on the GPU. So newer mesa code is sending
a command submission with an invalid vbo size. As such the kernel
driver rejects the command submission.
This may result in subtle rendering issues as the invalid command
submission does not get sent to the hardware. I would suggest filing
a mesa bug report:
https://gitlab.freedesktop.org/mesa/mesa/-/issues"
So users are encouraged to report this bug if they catch it in their
dmesg.
Signed-off-by: Borislav Petkov (AMD) <bp@...en8.de>
Link: https://lore.kernel.org/r/20250829171655.GBaLHgh3VOvuM1UfJg@fat_crate.local
---
drivers/gpu/drm/radeon/evergreen_cs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c b/drivers/gpu/drm/radeon/evergreen_cs.c
index a46613283393..6285ff1b1bff 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -2418,7 +2418,7 @@ static int evergreen_packet3_check(struct radeon_cs_parser *p,
size = radeon_get_ib_value(p, idx+1+(i*8)+1);
if (p->rdev && (size + offset) > radeon_bo_size(reloc->robj)) {
/* force size to size of the buffer */
- dev_warn_ratelimited(p->dev, "vbo resource seems too big for the bo\n");
+ dev_warn_once(p->dev, "vbo resource seems too big for the bo\n");
ib[idx+1+(i*8)+1] = radeon_bo_size(reloc->robj) - offset;
}
--
2.51.0
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists