Bug 82162

Just a quick update, the spam does not begin until I'm in 3D mode. Once I'm in 3D mode, the spam is constantly and very quick. Once I quit the 3D application, it slows down but is still there. The only way to stop this is to restart X or the computer.

Ignore the last comment, spam is constant.

Looks like the Mesa radeonsi driver tries to allocate buffer objects of zero bytes size, which isn't allowed.

Since nobody else has reported this, I wonder if your driver binaries got corrupted somehow. Does uninstalling the PPA and installing it again help?

(In reply to comment #3)
> Looks like the Mesa radeonsi driver tries to allocate buffer objects of zero
> bytes size, which isn't allowed.
> 
> Since nobody else has reported this, I wonder if your driver binaries got
> corrupted somehow. Does uninstalling the PPA and installing it again help?

Hi Michael, thanks for your response. Since PPA-Purge doesn't work for me with this PPA, I decided to reinstall the OS. All I have done since the stock Mint 17 install is update the packages and install the oibaf PPA. When running dmesg, I see the same errors as before. 

[   67.914111] [TTM] Illegal buffer object size
[   67.914113] [TTM] Illegal buffer object size
[   67.914115] [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (0, 6, 4096, -22)

Any ideas?

I've been having the same problem on Arch Linux for a while now with my Radeon HD 7950 too. My Kabini laptop, which is also radeonsi, isn't affected. Dmesg spams the following messages repeatedly:

[ 3069.134039] [TTM] Illegal buffer object size
[ 3069.134046] [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (0, 6, 4096, -22)

I tried running a 3D game using the terminal to monitor stdout, and this was constantly spammed as well. Not sure if it gives any additional information.

radeon: Failed to allocate a buffer:
radeon:    size      : 0 bytes
radeon:    alignment : 4096 bytes
radeon:    domains   : 4
radeon:    flags     : 4

(In reply to comment #6)
> I tried running a 3D game using the terminal to monitor stdout, and this was
> constantly spammed as well. Not sure if it gives any additional information.
> 
> radeon: Failed to allocate a buffer:
> radeon:    size      : 0 bytes
> radeon:    alignment : 4096 bytes
> radeon:    domains   : 4
> radeon:    flags     : 4

Yeah, pretty much the same message from userspace.

Looks like a bug in the userspace driver somewhere. Simplest thing to find it would be to attach a debugger and get a backtrace when the message is printed.

(In reply to comment #7)
> (In reply to comment #6)
> > I tried running a 3D game using the terminal to monitor stdout, and this was
> > constantly spammed as well. Not sure if it gives any additional information.
> > 
> > radeon: Failed to allocate a buffer:
> > radeon:    size      : 0 bytes
> > radeon:    alignment : 4096 bytes
> > radeon:    domains   : 4
> > radeon:    flags     : 4
> 
> Yeah, pretty much the same message from userspace.
> 
> Looks like a bug in the userspace driver somewhere. Simplest thing to find
> it would be to attach a debugger and get a backtrace when the message is
> printed.

Hi, thanks for the response. I don't really know what I'm doing with GDB so I'll explain what I did to get this output. I installed all of the dbg mesa packages from the PPA. Then, I ran the command "LIBGL_DEBUG=verbose gdb glxgears", and when error printed(immedaitely), I pressed Ctrl+C and then typed bt full. If there's another way to do this please let me know.

http://pastebin.com/v1nA7JWY

You need to set a breakpoint in the function printing the messages before running glxgears. Something like

 b radeon_bomgr_create_bo if size == 0

should do the trick. Then get the backtrace when the breakpoint triggers.

(In reply to comment #9)
> You need to set a breakpoint in the function printing the messages before
> running glxgears. Something like
> 
>  b radeon_bomgr_create_bo if size == 0
> 
> should do the trick. Then get the backtrace when the breakpoint triggers.

Hi Michael, here's the backtrace from that breakpoint. Please let me know if you need anything I really want this bug fixed.


http://pastebin.com/Lw6rtfg8

Created attachment 104132 [details] [review]
r600g/radeon: Don't try to allocate CMASK BO of size 0

This patch should at least work around the problem, but I'm not sure it's the proper fix.

(In reply to comment #11)
> Created attachment 104132 [details] [review] [review]
> r600g/radeon: Don't try to allocate CMASK BO of size 0
> 
> This patch should at least work around the problem, but I'm not sure it's
> the proper fix.

Michel, the patch appears to fix the problem without any sideeffects. Is there any chance of it getting into the main git? Thanks.

Sorry, it appears the issue has not been fixed. The message "radeon: Failed to allocate a buffer" no longer prints, but the original radeon_gem_object_create message still spams dmesg and kern.log.

(In reply to comment #13)
> Sorry, it appears the issue has not been fixed. The message "radeon: Failed
> to allocate a buffer" no longer prints, but the original
> radeon_gem_object_create message still spams dmesg and kern.log.

Did you restart X after building Mesa with the patch?

(In reply to comment #14)
> (In reply to comment #13)
> > Sorry, it appears the issue has not been fixed. The message "radeon: Failed
> > to allocate a buffer" no longer prints, but the original
> > radeon_gem_object_create message still spams dmesg and kern.log.
> 
> Did you restart X after building Mesa with the patch?

Wow, I'm an idiot. Yeah, everything is completely fixed after restarting X. No side effects or log spam. Thank you based Michel.

Any chance of seeing this in the git?

(In reply to comment #16)
> Any chance of seeing this in the git?

Yeah, but we might want to investigate further.

Somehow the size for the CMASK buffer ends up beeing zero. It's good to catch that case, but we might want to figure out why it happened in the first place.

(In reply to comment #17)
> (In reply to comment #16)
> > Any chance of seeing this in the git?
> 
> Yeah, but we might want to investigate further.
> 
> Somehow the size for the CMASK buffer ends up beeing zero. It's good to
> catch that case, but we might want to figure out why it happened in the
> first place.

Anything I can do to help?

Could you please set a breakpoint in si_texture_get_cmask_info and print:

rscreen->tiling_info AND rscreen->info

OR

pipe_interleave_bytes AND num_pipes

Thanks.

(In reply to comment #19)
> Could you please set a breakpoint in si_texture_get_cmask_info and print:
> 
> rscreen->tiling_info AND rscreen->info
> 
> OR
> 
> pipe_interleave_bytes AND num_pipes
> 
> Thanks.

Hi Marek, 

As I said earlier I don't know what I'm doing with GDB.I set the breakpoint with "b si_texture_get_cmask_info", please let me know if that is wrong.

Here is the output from all of those:

(gdb) p rscreen->tiling_info
value has been optimized out
(gdb) p rscreen->info
value has been optimized out


(gdb) p pipe_interleave_bytes
$1 = 256
(gdb) p num_pipes
$2 = 12

Thanks. The real problem is that num_pipes is 12. That's good to know. I guess I just need to get the number of pipes from GB_TILE_MODE, because that's what we need for CMASK and HTILE calculations. That would be P8 or 8 pipes.

(In reply to comment #21)
> Thanks. The real problem is that num_pipes is 12. That's good to know. I
> guess I just need to get the number of pipes from GB_TILE_MODE, because
> that's what we need for CMASK and HTILE calculations. That would be P8 or 8
> pipes.

Awesome, any more information you need from me? I can test any fixes.

Would be nice to get a patch out for the stable mesa builds as they are also affected by this bug.

Fixed by 955505f6ff1c8bba7eb142200d3bd065eb4d2297. The commit has been nominated for inclusion in the next stable release. Closing.

(In reply to comment #24)
> Fixed by 955505f6ff1c8bba7eb142200d3bd065eb4d2297. The commit has been
> nominated for inclusion in the next stable release. Closing.

Thank you very much!

After compiling the latest version of mesa from git, I'm still getting this bug with my Radeon HD 7950 spamming the system log.

[  372.835016] [TTM] Illegal buffer object size
[  372.835019] [TTM] Illegal buffer object size
[  372.835021] [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (0, 6, 4096, -22)

So it doesn't seem to be fixed for me at least.

(In reply to comment #26)
> After compiling the latest version of mesa from git, I'm still getting this
> bug with my Radeon HD 7950 spamming the system log.
> 
> [  372.835016] [TTM] Illegal buffer object size
> [  372.835019] [TTM] Illegal buffer object size
> [  372.835021] [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM
> object (0, 6, 4096, -22)
> 
> So it doesn't seem to be fixed for me at least.

You need to compile the 32 bit mesa packages you are using as well. It's must easier to just install the oibaf PPA. I have no issues after the fix.

That's right -- it's working now. No need for PPAs on Arch when you have the AUR. There's also a pacman repository for mesa-git that compiles daily so it's just a matter of installing lib32-mesa-git and mesa-git.

(In reply to comment #28)
> That's right -- it's working now. No need for PPAs on Arch when you have the
> AUR. There's also a pacman repository for mesa-git that compiles daily so
> it's just a matter of installing lib32-mesa-git and mesa-git.

Ah, I'm a debian-based plebian. Glad to see it works.

*** Bug 82783 has been marked as a duplicate of this bug. ***