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