* evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo
@ 2025-08-29 17:16 Borislav Petkov
2025-08-29 18:26 ` Alex Deucher
0 siblings, 1 reply; 10+ messages in thread
From: Borislav Petkov @ 2025-08-29 17:16 UTC (permalink / raw)
To: amd-gfx
Cc: Alex Deucher, Christian König, amd-gfx, dri-devel,
linux-kernel
Heya folks,
this flood happens with plain 6.16 on my workstation - haven't done any hw
changes:
[ 29.094609] evergreen_packet3_check: 115 callbacks suppressed
[ 29.094615] radeon 0000:1d:00.0: vbo resource seems too big for the bo
[ 29.106737] radeon 0000:1d:00.0: vbo resource seems too big for the bo
[ 29.106740] radeon 0000:1d:00.0: vbo resource seems too big for the bo
[ 29.106742] radeon 0000:1d:00.0: vbo resource seems too big for the bo
[ 29.106745] radeon 0000:1d:00.0: vbo resource seems too big for the bo
[ 29.106747] radeon 0000:1d:00.0: vbo resource seems too big for the bo
[ 29.106750] radeon 0000:1d:00.0: vbo resource seems too big for the bo
[ 29.106752] radeon 0000:1d:00.0: vbo resource seems too big for the bo
[ 29.106754] radeon 0000:1d:00.0: vbo resource seems too big for the bo
[ 29.106757] radeon 0000:1d:00.0: vbo resource seems too big for the bo
[ 52.579786] evergreen_packet3_check: 29 callbacks suppressed
[ 52.579792] radeon 0000:1d:00.0: vbo resource seems too big for the bo
[ 52.591825] radeon 0000:1d:00.0: vbo resource seems too big for the bo
[ 52.591829] radeon 0000:1d:00.0: vbo resource seems too big for the bo
[ 52.591832] radeon 0000:1d:00.0: vbo resource seems too big for the bo
[ 52.591835] radeon 0000:1d:00.0: vbo resource seems too big for the bo
[ 52.591838] radeon 0000:1d:00.0: vbo resource seems too big for the bo
[ 52.591840] radeon 0000:1d:00.0: vbo resource seems too big for the bo
[ 52.591843] radeon 0000:1d:00.0: vbo resource seems too big for the bo
[ 52.591846] radeon 0000:1d:00.0: vbo resource seems too big for the bo
[ 52.591849] radeon 0000:1d:00.0: vbo resource seems too big for the bo
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo 2025-08-29 17:16 evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo Borislav Petkov @ 2025-08-29 18:26 ` Alex Deucher 2025-08-29 19:40 ` Borislav Petkov 0 siblings, 1 reply; 10+ messages in thread From: Alex Deucher @ 2025-08-29 18:26 UTC (permalink / raw) To: Borislav Petkov Cc: amd-gfx, Alex Deucher, Christian König, dri-devel, linux-kernel On Fri, Aug 29, 2025 at 1:53 PM Borislav Petkov <bp@alien8.de> wrote: > > Heya folks, > > this flood happens with plain 6.16 on my workstation - haven't done any hw > changes: Have you updated mesa? Looks like a userspace change. Alex > > [ 29.094609] evergreen_packet3_check: 115 callbacks suppressed > [ 29.094615] radeon 0000:1d:00.0: vbo resource seems too big for the bo > [ 29.106737] radeon 0000:1d:00.0: vbo resource seems too big for the bo > [ 29.106740] radeon 0000:1d:00.0: vbo resource seems too big for the bo > [ 29.106742] radeon 0000:1d:00.0: vbo resource seems too big for the bo > [ 29.106745] radeon 0000:1d:00.0: vbo resource seems too big for the bo > [ 29.106747] radeon 0000:1d:00.0: vbo resource seems too big for the bo > [ 29.106750] radeon 0000:1d:00.0: vbo resource seems too big for the bo > [ 29.106752] radeon 0000:1d:00.0: vbo resource seems too big for the bo > [ 29.106754] radeon 0000:1d:00.0: vbo resource seems too big for the bo > [ 29.106757] radeon 0000:1d:00.0: vbo resource seems too big for the bo > [ 52.579786] evergreen_packet3_check: 29 callbacks suppressed > [ 52.579792] radeon 0000:1d:00.0: vbo resource seems too big for the bo > [ 52.591825] radeon 0000:1d:00.0: vbo resource seems too big for the bo > [ 52.591829] radeon 0000:1d:00.0: vbo resource seems too big for the bo > [ 52.591832] radeon 0000:1d:00.0: vbo resource seems too big for the bo > [ 52.591835] radeon 0000:1d:00.0: vbo resource seems too big for the bo > [ 52.591838] radeon 0000:1d:00.0: vbo resource seems too big for the bo > [ 52.591840] radeon 0000:1d:00.0: vbo resource seems too big for the bo > [ 52.591843] radeon 0000:1d:00.0: vbo resource seems too big for the bo > [ 52.591846] radeon 0000:1d:00.0: vbo resource seems too big for the bo > [ 52.591849] radeon 0000:1d:00.0: vbo resource seems too big for the bo > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo 2025-08-29 18:26 ` Alex Deucher @ 2025-08-29 19:40 ` Borislav Petkov 2025-08-29 20:48 ` Borislav Petkov 0 siblings, 1 reply; 10+ messages in thread From: Borislav Petkov @ 2025-08-29 19:40 UTC (permalink / raw) To: Alex Deucher Cc: amd-gfx, Alex Deucher, Christian König, dri-devel, linux-kernel On Fri, Aug 29, 2025 at 02:26:50PM -0400, Alex Deucher wrote: > Have you updated mesa? Looks like a userspace change. Yeah, I did a long overdue OS upgrade today: $ grep -i mesa /var/log/dpkg.log 2025-08-29 17:50:32 install mesa-libgallium:amd64 <none> 25.0.7-2 2025-08-29 17:50:32 status half-installed mesa-libgallium:amd64 25.0.7-2 2025-08-29 17:50:33 status unpacked mesa-libgallium:amd64 25.0.7-2 2025-08-29 17:50:33 upgrade libegl-mesa0:amd64 21.3.8-1 25.0.7-2 2025-08-29 17:50:33 status half-configured libegl-mesa0:amd64 21.3.8-1 2025-08-29 17:50:33 status unpacked libegl-mesa0:amd64 21.3.8-1 2025-08-29 17:50:33 status half-installed libegl-mesa0:amd64 21.3.8-1 2025-08-29 17:50:33 status unpacked libegl-mesa0:amd64 25.0.7-2 2025-08-29 17:50:34 upgrade libgl1-mesa-dri:amd64 21.3.8-1 25.0.7-2 2025-08-29 17:50:34 status half-configured libgl1-mesa-dri:amd64 21.3.8-1 2025-08-29 17:50:34 status unpacked libgl1-mesa-dri:amd64 21.3.8-1 2025-08-29 17:50:34 status half-installed libgl1-mesa-dri:amd64 21.3.8-1 2025-08-29 17:50:34 status unpacked libgl1-mesa-dri:amd64 25.0.7-2 2025-08-29 17:50:34 upgrade libglx-mesa0:amd64 21.3.8-1 25.0.7-2 2025-08-29 17:50:34 status half-configured libglx-mesa0:amd64 21.3.8-1 2025-08-29 17:50:34 status unpacked libglx-mesa0:amd64 21.3.8-1 2025-08-29 17:50:34 status half-installed libglx-mesa0:amd64 21.3.8-1 2025-08-29 17:50:34 status unpacked libglx-mesa0:amd64 25.0.7-2 2025-08-29 17:50:45 upgrade libegl1-mesa-dev:amd64 21.3.8-1 25.0.7-2 2025-08-29 17:50:45 status half-configured libegl1-mesa-dev:amd64 21.3.8-1 2025-08-29 17:50:45 status unpacked libegl1-mesa-dev:amd64 21.3.8-1 2025-08-29 17:50:45 status half-installed libegl1-mesa-dev:amd64 21.3.8-1 2025-08-29 17:50:45 status unpacked libegl1-mesa-dev:amd64 25.0.7-2 2025-08-29 17:51:47 upgrade libglu1-mesa-dev:amd64 9.0.2-1 9.0.2-1.1+b3 2025-08-29 17:51:47 status half-configured libglu1-mesa-dev:amd64 9.0.2-1 2025-08-29 17:51:47 status unpacked libglu1-mesa-dev:amd64 9.0.2-1 2025-08-29 17:51:47 status half-installed libglu1-mesa-dev:amd64 9.0.2-1 2025-08-29 17:51:47 status unpacked libglu1-mesa-dev:amd64 9.0.2-1.1+b3 2025-08-29 17:51:47 upgrade libglu1-mesa:amd64 9.0.2-1 9.0.2-1.1+b3 2025-08-29 17:51:47 status half-configured libglu1-mesa:amd64 9.0.2-1 2025-08-29 17:51:47 status unpacked libglu1-mesa:amd64 9.0.2-1 2025-08-29 17:51:47 status half-installed libglu1-mesa:amd64 9.0.2-1 2025-08-29 17:51:47 status unpacked libglu1-mesa:amd64 9.0.2-1.1+b3 2025-08-29 17:57:11 upgrade mesa-va-drivers:amd64 21.3.8-1 25.0.7-2 2025-08-29 17:57:11 status half-configured mesa-va-drivers:amd64 21.3.8-1 2025-08-29 17:57:11 status unpacked mesa-va-drivers:amd64 21.3.8-1 2025-08-29 17:57:11 status half-installed mesa-va-drivers:amd64 21.3.8-1 2025-08-29 17:57:12 status unpacked mesa-va-drivers:amd64 25.0.7-2 2025-08-29 17:57:12 upgrade mesa-vdpau-drivers:amd64 21.3.8-1 25.0.7-2 2025-08-29 17:57:12 status half-configured mesa-vdpau-drivers:amd64 21.3.8-1 2025-08-29 17:57:12 status unpacked mesa-vdpau-drivers:amd64 21.3.8-1 2025-08-29 17:57:12 status half-installed mesa-vdpau-drivers:amd64 21.3.8-1 2025-08-29 17:57:12 status unpacked mesa-vdpau-drivers:amd64 25.0.7-2 2025-08-29 17:57:12 upgrade mesa-vulkan-drivers:amd64 21.3.8-1 25.0.7-2 2025-08-29 17:57:12 status half-configured mesa-vulkan-drivers:amd64 21.3.8-1 2025-08-29 17:57:12 status unpacked mesa-vulkan-drivers:amd64 21.3.8-1 2025-08-29 17:57:12 status half-installed mesa-vulkan-drivers:amd64 21.3.8-1 2025-08-29 17:57:12 status unpacked mesa-vulkan-drivers:amd64 25.0.7-2 2025-08-29 18:00:32 configure libglu1-mesa:amd64 9.0.2-1.1+b3 <none> 2025-08-29 18:00:32 status unpacked libglu1-mesa:amd64 9.0.2-1.1+b3 2025-08-29 18:00:32 status half-configured libglu1-mesa:amd64 9.0.2-1.1+b3 2025-08-29 18:00:32 status installed libglu1-mesa:amd64 9.0.2-1.1+b3 2025-08-29 18:09:41 configure mesa-vulkan-drivers:amd64 25.0.7-2 <none> 2025-08-29 18:09:41 status unpacked mesa-vulkan-drivers:amd64 25.0.7-2 2025-08-29 18:09:41 status half-configured mesa-vulkan-drivers:amd64 25.0.7-2 2025-08-29 18:09:41 status installed mesa-vulkan-drivers:amd64 25.0.7-2 2025-08-29 18:09:41 configure mesa-vdpau-drivers:amd64 25.0.7-2 <none> 2025-08-29 18:09:41 status unpacked mesa-vdpau-drivers:amd64 25.0.7-2 2025-08-29 18:09:41 status half-configured mesa-vdpau-drivers:amd64 25.0.7-2 2025-08-29 18:09:41 status installed mesa-vdpau-drivers:amd64 25.0.7-2 2025-08-29 18:11:26 configure mesa-libgallium:amd64 25.0.7-2 <none> 2025-08-29 18:11:26 status unpacked mesa-libgallium:amd64 25.0.7-2 2025-08-29 18:11:26 status half-configured mesa-libgallium:amd64 25.0.7-2 2025-08-29 18:11:26 status installed mesa-libgallium:amd64 25.0.7-2 2025-08-29 18:11:27 configure libgl1-mesa-dri:amd64 25.0.7-2 <none> 2025-08-29 18:11:27 status unpacked libgl1-mesa-dri:amd64 25.0.7-2 2025-08-29 18:11:27 status half-configured libgl1-mesa-dri:amd64 25.0.7-2 2025-08-29 18:11:27 status installed libgl1-mesa-dri:amd64 25.0.7-2 2025-08-29 18:11:28 configure libegl-mesa0:amd64 25.0.7-2 <none> 2025-08-29 18:11:28 status unpacked libegl-mesa0:amd64 25.0.7-2 2025-08-29 18:11:28 status half-configured libegl-mesa0:amd64 25.0.7-2 2025-08-29 18:11:28 status installed libegl-mesa0:amd64 25.0.7-2 2025-08-29 18:11:29 configure mesa-va-drivers:amd64 25.0.7-2 <none> 2025-08-29 18:11:29 status unpacked mesa-va-drivers:amd64 25.0.7-2 2025-08-29 18:11:29 status half-configured mesa-va-drivers:amd64 25.0.7-2 2025-08-29 18:11:29 status installed mesa-va-drivers:amd64 25.0.7-2 2025-08-29 18:11:29 configure libglx-mesa0:amd64 25.0.7-2 <none> 2025-08-29 18:11:29 status unpacked libglx-mesa0:amd64 25.0.7-2 2025-08-29 18:11:29 status half-configured libglx-mesa0:amd64 25.0.7-2 2025-08-29 18:11:29 status installed libglx-mesa0:amd64 25.0.7-2 2025-08-29 18:11:31 configure libglu1-mesa-dev:amd64 9.0.2-1.1+b3 <none> 2025-08-29 18:11:31 status unpacked libglu1-mesa-dev:amd64 9.0.2-1.1+b3 2025-08-29 18:11:31 status half-configured libglu1-mesa-dev:amd64 9.0.2-1.1+b3 2025-08-29 18:11:31 status installed libglu1-mesa-dev:amd64 9.0.2-1.1+b3 2025-08-29 18:11:32 configure libegl1-mesa-dev:amd64 25.0.7-2 <none> 2025-08-29 18:11:32 status unpacked libegl1-mesa-dev:amd64 25.0.7-2 2025-08-29 18:11:32 status half-configured libegl1-mesa-dev:amd64 25.0.7-2 2025-08-29 18:11:32 status installed libegl1-mesa-dev:amd64 25.0.7-2 2025-08-29 18:14:28 status installed libglapi-mesa:amd64 21.3.8-1 2025-08-29 18:14:28 remove libglapi-mesa:amd64 21.3.8-1 <none> 2025-08-29 18:14:28 status half-configured libglapi-mesa:amd64 21.3.8-1 2025-08-29 18:14:28 status half-installed libglapi-mesa:amd64 21.3.8-1 2025-08-29 18:14:28 status config-files libglapi-mesa:amd64 21.3.8-1 2025-08-29 18:14:28 status not-installed libglapi-mesa:amd64 <none> 2025-08-29 18:14:28 status installed libglu1-mesa-dev:amd64 9.0.2-1.1+b3 2025-08-29 18:14:28 remove libglu1-mesa-dev:amd64 9.0.2-1.1+b3 <none> 2025-08-29 18:14:28 status half-configured libglu1-mesa-dev:amd64 9.0.2-1.1+b3 2025-08-29 18:14:28 status half-installed libglu1-mesa-dev:amd64 9.0.2-1.1+b3 2025-08-29 18:14:28 status config-files libglu1-mesa-dev:amd64 9.0.2-1.1+b3 2025-08-29 18:14:28 status not-installed libglu1-mesa-dev:amd64 <none> -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo 2025-08-29 19:40 ` Borislav Petkov @ 2025-08-29 20:48 ` Borislav Petkov 2025-08-30 16:30 ` Alex Deucher 0 siblings, 1 reply; 10+ messages in thread From: Borislav Petkov @ 2025-08-29 20:48 UTC (permalink / raw) To: Alex Deucher Cc: amd-gfx, Alex Deucher, Christian König, dri-devel, linux-kernel On Fri, Aug 29, 2025 at 09:40:44PM +0200, Borislav Petkov wrote: > On Fri, Aug 29, 2025 at 02:26:50PM -0400, Alex Deucher wrote: > > Have you updated mesa? Looks like a userspace change. > > Yeah, I did a long overdue OS upgrade today: > > $ grep -i mesa /var/log/dpkg.log Btw, this thing: 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"); ib[idx+1+(i*8)+1] = radeon_bo_size(reloc->robj) - offset; } is yet another example of useless flooding of dmesg. It's not like I can do anything about it except report it. And that thing fires every 5s or so. You could consider turning that into a _once thing and be done with it. And someone already ratelimited them: 59d76d6bc206 ("drm/radeon: ratelimit bo warnings") but it ain't enough. $ dmesg | grep "vbo resource" | wc -l 22393 So even if I go and find which commit added it: cb5fcbd540b4 ("drm/radeon/kms/evergreen: add initial CS parser") I'm still none the wiser. And I'm not even a normal user - I have seen kernel code in the past :-) Hell, I don't even know what CS is... /me goes and searches the web a bit... Aha, it could be a command submission parser or so. Still have no clue what this warning is telling me. Going back to searching the web... ok, so it looks like this is validating some packet3 set resource thing and when the resource type? is a SQ_TEX_VTX_VALID_BUFFER - perhaps a valid vertex buffer? Vertex buffer I understand. But texture vertex buffer? Anyway, it checks whether the vbo (vertex buffer object?) resource is too big for the buffer object which has gotten as some sort of a relocation packet 3 thing... And I still have no clue what is going on. Perhaps the new MESA is sending wrong command types, who knows. I absolutely cannot fix it - that's for sure. And so this rambling of mine confirms my old theory that the warning and error messages we put in the kernel are not really useful. Especially to users. Because there isn't a whole lot they can do about them except reporting them to those who can actually do something about. I.e., those messages might as well be hashes which we can stick into a lookup table to fish out a longer string which tells us what is going on. So I *think* you should make this a once message or *at* *least* ratelimit the hell of it so that it appears very seldomly. The rule of thumb should be what you want this message to do? To make a user report it to you? Or something else? In any case, I am already very picky with the error messages visible to users in the code I'm maintaining, this'll make me be even stricter. Oh well. Thanks for listening. :-) -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo 2025-08-29 20:48 ` Borislav Petkov @ 2025-08-30 16:30 ` Alex Deucher 2025-08-30 17:48 ` Borislav Petkov 0 siblings, 1 reply; 10+ messages in thread From: Alex Deucher @ 2025-08-30 16:30 UTC (permalink / raw) To: Borislav Petkov Cc: amd-gfx, Alex Deucher, Christian König, dri-devel, linux-kernel On Fri, Aug 29, 2025 at 4:48 PM Borislav Petkov <bp@alien8.de> wrote: > > On Fri, Aug 29, 2025 at 09:40:44PM +0200, Borislav Petkov wrote: > > On Fri, Aug 29, 2025 at 02:26:50PM -0400, Alex Deucher wrote: > > > Have you updated mesa? Looks like a userspace change. > > > > Yeah, I did a long overdue OS upgrade today: > > > > $ grep -i mesa /var/log/dpkg.log > > Btw, this thing: > > 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"); > ib[idx+1+(i*8)+1] = radeon_bo_size(reloc->robj) - offset; > } > > is yet another example of useless flooding of dmesg. > > It's not like I can do anything about it except report it. And that thing > fires every 5s or so. > > You could consider turning that into a _once thing and be done with it. > > And someone already ratelimited them: > > 59d76d6bc206 ("drm/radeon: ratelimit bo warnings") > > but it ain't enough. > > $ dmesg | grep "vbo resource" | wc -l > 22393 > > So even if I go and find which commit added it: > > cb5fcbd540b4 ("drm/radeon/kms/evergreen: add initial CS parser") > > I'm still none the wiser. And I'm not even a normal user - I have seen kernel > code in the past :-) > > Hell, I don't even know what CS is... > > /me goes and searches the web a bit... > > Aha, it could be a command submission parser or so. Still have no clue what > this warning is telling me. > > Going back to searching the web... > > ok, so it looks like this is validating some packet3 set resource thing and > when the resource type? is a SQ_TEX_VTX_VALID_BUFFER - perhaps a valid vertex > buffer? Vertex buffer I understand. But texture vertex buffer? > > Anyway, it checks whether the vbo (vertex buffer object?) resource is > too big for the buffer object which has gotten as some sort of a relocation > packet 3 thing... > > And I still have no clue what is going on. Perhaps the new MESA is sending > wrong command types, who knows. > > I absolutely cannot fix it - that's for sure. > > And so this rambling of mine confirms my old theory that the warning and error > messages we put in the kernel are not really useful. Especially to users. > > Because there isn't a whole lot they can do about them except reporting them > to those who can actually do something about. > > I.e., those messages might as well be hashes which we can stick into a lookup > table to fish out a longer string which tells us what is going on. > > So I *think* you should make this a once message or *at* *least* ratelimit the > hell of it so that it appears very seldomly. The rule of thumb should be what > you want this message to do? > > To make a user report it to you? > > Or something else? > > In any case, I am already very picky with the error messages visible to users > in the code I'm maintaining, this'll make me be even stricter. > > Oh well. 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. 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. I would suggest filing a mesa bug report: https://gitlab.freedesktop.org/mesa/mesa/-/issues/ Alex ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo 2025-08-30 16:30 ` Alex Deucher @ 2025-08-30 17:48 ` Borislav Petkov 2025-08-31 21:42 ` Timur Kristóf 2025-09-01 9:27 ` Michel Dänzer 0 siblings, 2 replies; 10+ messages in thread From: Borislav Petkov @ 2025-08-30 17:48 UTC (permalink / raw) To: Alex Deucher Cc: amd-gfx, Alex Deucher, Christian König, dri-devel, linux-kernel 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@alien8.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@alien8.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 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo 2025-08-30 17:48 ` Borislav Petkov @ 2025-08-31 21:42 ` Timur Kristóf 2025-08-31 22:08 ` Borislav Petkov 2025-09-01 9:27 ` Michel Dänzer 1 sibling, 1 reply; 10+ messages in thread From: Timur Kristóf @ 2025-08-31 21:42 UTC (permalink / raw) To: Borislav Petkov, Alex Deucher Cc: amd-gfx, Alex Deucher, Christian König, dri-devel, linux-kernel On Sat, 2025-08-30 at 19:48 +0200, Borislav Petkov wrote: > > > With newer MESA (version 9.0.2 in Debian), the message Which Mesa version do you use exactly? Are you sure that version number is correct? Mesa 9.0.2 was released on January 22nd, 2013, more than 12 years ago. Timur ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo 2025-08-31 21:42 ` Timur Kristóf @ 2025-08-31 22:08 ` Borislav Petkov 0 siblings, 0 replies; 10+ messages in thread From: Borislav Petkov @ 2025-08-31 22:08 UTC (permalink / raw) To: Timur Kristóf Cc: Alex Deucher, amd-gfx, Alex Deucher, Christian König, dri-devel, linux-kernel On Sun, Aug 31, 2025 at 11:42:19PM +0200, Timur Kristóf wrote: > Which Mesa version do you use exactly? > Are you sure that version number is correct? > > Mesa 9.0.2 was released on January 22nd, 2013, more than 12 years ago. How's that? $ glxinfo | grep Mesa client glx vendor string: Mesa Project and SGI Vendor: Mesa (0x1002) OpenGL vendor string: Mesa OpenGL core profile version string: 4.5 (Core Profile) Mesa 25.0.7-2 OpenGL version string: 4.5 (Compatibility Profile) Mesa 25.0.7-2 OpenGL ES profile version string: OpenGL ES 3.1 Mesa 25.0.7-2 -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo 2025-08-30 17:48 ` Borislav Petkov 2025-08-31 21:42 ` Timur Kristóf @ 2025-09-01 9:27 ` Michel Dänzer 2025-09-01 10:10 ` Borislav Petkov 1 sibling, 1 reply; 10+ messages in thread From: Michel Dänzer @ 2025-09-01 9:27 UTC (permalink / raw) To: Borislav Petkov, Alex Deucher Cc: amd-gfx, Alex Deucher, Christian König, dri-devel, linux-kernel On 30.08.25 19:48, Borislav Petkov wrote: > > 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; > } > Like all scenarios which can be triggered by user space, this should rather use some kind of debug output API which doesn't hit dmesg by default (can be a non-once variant instead, that's more useful for user-space developers). -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo 2025-09-01 9:27 ` Michel Dänzer @ 2025-09-01 10:10 ` Borislav Petkov 0 siblings, 0 replies; 10+ messages in thread From: Borislav Petkov @ 2025-09-01 10:10 UTC (permalink / raw) To: Michel Dänzer Cc: Alex Deucher, amd-gfx, Alex Deucher, Christian König, dri-devel, linux-kernel On Mon, Sep 01, 2025 at 11:27:01AM +0200, Michel Dänzer wrote: > use some kind of debug output API which doesn't hit dmesg by default You still want to be enabled by default so that normal users can see it and actually report it. > (can be a non-once variant instead, that's more useful for user-space > developers). I don't see how a non-once variant can tell you anything new - it is repeating one cryptic message to most users so what's the point of parroting it more than once? IMO, that message should be beefed up to have more information, dump it once and encourage users to report it. Then, whoever gets to debug it, will ask for a reproducer and then do their own kernel patching to add more info and make the message more useful to them when debugging the thing. At least this is how I would do it... -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2025-09-01 10:10 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-08-29 17:16 evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo Borislav Petkov 2025-08-29 18:26 ` Alex Deucher 2025-08-29 19:40 ` Borislav Petkov 2025-08-29 20:48 ` Borislav Petkov 2025-08-30 16:30 ` Alex Deucher 2025-08-30 17:48 ` Borislav Petkov 2025-08-31 21:42 ` Timur Kristóf 2025-08-31 22:08 ` Borislav Petkov 2025-09-01 9:27 ` Michel Dänzer 2025-09-01 10:10 ` Borislav Petkov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).