evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo

evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo

[Borislav Petkov]

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

Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo

[Alex Deucher]

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

Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo

[Borislav Petkov]

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

Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo

[Borislav Petkov]

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

Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo

[Alex Deucher]

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

Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo

[Borislav Petkov]

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

Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo

[Timur Kristóf]

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

Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo

[Borislav Petkov]

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

Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo

[Michel Dänzer]

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

Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo

[Borislav Petkov]

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

Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo

[Michel Dänzer]

On 01.09.25 12:10, Borislav Petkov wrote:
> 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.

These messages are primarily intended for developers, not users (which will notice and report the corresponding user-space issues instead).


>> (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?

The once variant means user-space developers need to reboot after hitting it once.


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast

Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo

[Borislav Petkov]

On Mon, Sep 08, 2025 at 07:05:17PM +0200, Michel Dänzer wrote:
> These messages are primarily intended for developers, not users

But everybody sees them! And they're flooding the console.

And most people seeing them are users, not developers.

And if those messages are only for developers, they better be not visible by
default but behind a CONFIG_DEBUG or a similar switch.

And developers don't have every hw to test on. So you need to rely on users to
report issues to you. Because those messages probably don't fire on your hw
but someone else would hit them. And the chances are high that someone else is
a user.

So you want to make *all* your messages for users and have them report them
back to you.

> (which will notice and report the corresponding user-space issues instead).

The case due to which we're having this conversation didn't manifest itself
into anything - it was only flooding my dmesg. So users will notice nothing.

> The once variant means user-space developers need to reboot after hitting it
> once.

/sys/kernel/debug/clear_warn_once

Although when I tried it, it didn't help with dev_warn_once(). Perhaps needs
adding.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo

[Michel Dänzer]

On 08.09.25 20:00, Borislav Petkov wrote:
> On Mon, Sep 08, 2025 at 07:05:17PM +0200, Michel Dänzer wrote:
>> These messages are primarily intended for developers, not users
> 
> But everybody sees them! And they're flooding the console.

There's no question that dev_warn_ratelimited is wrong here, I'm just saying dev_warn_once isn't quite right either.


BTW, the same arguments apply to the other dev_warn calls in evergreen_cs.c. Their conditions can be controlled by user space, so they must not generate any dmesg output by default.


> And if those messages are only for developers, they better be not visible by
> default but behind a CONFIG_DEBUG or a similar switch.

Hence my suggestion to use a dbg variant, which isn't visible by default but can be enabled (and disabled again) at runtime.


> And developers don't have every hw to test on. So you need to rely on users to
> report issues to you. Because those messages probably don't fire on your hw
> but someone else would hit them. And the chances are high that someone else is
> a user.

Then the developer needs to tell the user how to enable the debugging output and get it to them. That's pretty standard.


>> (which will notice and report the corresponding user-space issues instead).
> 
> The case due to which we're having this conversation didn't manifest itself
> into anything - it was only flooding my dmesg.

The message is logged if the kernel needs to fix up invalid data passed in by user space. That may have had no noticeable effect in your case, it certainly could in other cases though.


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast

Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo

[Borislav Petkov]

On Tue, Sep 09, 2025 at 10:43:47AM +0200, Michel Dänzer wrote:
> Then the developer needs to tell the user how to enable the debugging output
> and get it to them. That's pretty standard.

*IF* the user even notices anything. As said earlier, it didn't cause any
anomalies on my machine besides flooding dmesg. Which I look at for obvious
reasons but users probably don't.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo

[Alex Deucher]

On Tue, Sep 9, 2025 at 12:17 PM Borislav Petkov <bp@alien8.de> wrote:
>
> On Tue, Sep 09, 2025 at 10:43:47AM +0200, Michel Dänzer wrote:
> > Then the developer needs to tell the user how to enable the debugging output
> > and get it to them. That's pretty standard.
>
> *IF* the user even notices anything. As said earlier, it didn't cause any
> anomalies on my machine besides flooding dmesg. Which I look at for obvious
> reasons but users probably don't.

Right.  I think there needs to be something otherwise no one will notice at all.

Alex

>
> --
> Regards/Gruss,
>     Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette

Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo

[Michel Dänzer]

On 09.09.25 18:21, Alex Deucher wrote:
> On Tue, Sep 9, 2025 at 12:17 PM Borislav Petkov <bp@alien8.de> wrote:
>> On Tue, Sep 09, 2025 at 10:43:47AM +0200, Michel Dänzer wrote:
>>> Then the developer needs to tell the user how to enable the debugging output
>>> and get it to them. That's pretty standard.
>>
>> *IF* the user even notices anything. As said earlier, it didn't cause any
>> anomalies on my machine besides flooding dmesg. Which I look at for obvious
>> reasons but users probably don't.
> 
> Right.  I think there needs to be something otherwise no one will notice at all.

I concede that in this specific case, dev_warn_once might be the best compromise.

(More to come in a follow-up to Alex's corresponding patch for the other similar log messages in this file)


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast

Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo

[Christian König]

On 09.09.25 18:21, Alex Deucher wrote:
> On Tue, Sep 9, 2025 at 12:17 PM Borislav Petkov <bp@alien8.de> wrote:
>>
>> On Tue, Sep 09, 2025 at 10:43:47AM +0200, Michel Dänzer wrote:
>>> Then the developer needs to tell the user how to enable the debugging output
>>> and get it to them. That's pretty standard.
>>
>> *IF* the user even notices anything. As said earlier, it didn't cause any
>> anomalies on my machine besides flooding dmesg. Which I look at for obvious
>> reasons but users probably don't.
> 
> Right.  I think there needs to be something otherwise no one will notice at all.

Well doesn't the cause of the warning result in corrupted rendering?

Christian.

> 
> Alex
> 
>>
>> --
>> Regards/Gruss,
>>     Boris.
>>
>> https://people.kernel.org/tglx/notes-about-netiquette

Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo

[Michel Dänzer]

On 10.09.25 10:02, Christian König wrote:
> On 09.09.25 18:21, Alex Deucher wrote:
>> On Tue, Sep 9, 2025 at 12:17 PM Borislav Petkov <bp@alien8.de> wrote:
>>>
>>> On Tue, Sep 09, 2025 at 10:43:47AM +0200, Michel Dänzer wrote:
>>>> Then the developer needs to tell the user how to enable the debugging output
>>>> and get it to them. That's pretty standard.
>>>
>>> *IF* the user even notices anything. As said earlier, it didn't cause any
>>> anomalies on my machine besides flooding dmesg. Which I look at for obvious
>>> reasons but users probably don't.
>>
>> Right.  I think there needs to be something otherwise no one will notice at all.
> 
> Well doesn't the cause of the warning result in corrupted rendering?

Per https://gitlab.freedesktop.org/mesa/mesa/-/issues/13838#note_3088335 it would result in one dropped vertex, which might be hard to notice. That's why I agree that in this specific case, not logging anything by default might have resulted in the issue taking much longer to be discovered (if ever).

(A potential counter argument being: If it's not noticeable, does the kernel need to log anything about it by default?)


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast