Bug 36952

Created attachment 46449 [details]
backtrace

I have some problem, and i have  ATI RS482 too, but i think it was the fault llvm, with out llvm or < 2.9 , all woks fine, with llvm > 2.8  openarena, urbanterror and some xscreensaver segfault. see https://bugs.freedesktop.org/show_bug.cgi?id=36738
I make backtrace with crackberg.

Can you bisect mesa?

But if I downgrade to mesa 7.10.2, I am still using llvm 2.9 and the
crackberg screensaver works correctly, so that would point to mesa-git
being the problem for me.  I cannot compile mesa-git without llvm as the
build process halts and complains that r300 gallium requires llvm to
build.  There are three gentoo patches that get applied on top of the
mesa 7.10.2-r1 build, I haven't looked at what they do yet.

(In reply to comment #2)
> I have some problem, and i have  ATI RS482 too, but i think it was the fault
> llvm, with out llvm or < 2.9 , all woks fine, with llvm > 2.8  openarena,
> urbanterror and some xscreensaver segfault. see
> https://bugs.freedesktop.org/show_bug.cgi?id=36738
> I make backtrace with crackberg.

I will try to bisect.  I have to figure out how to install mesa-git without the ebuild (and without messing up my dependencies), or is there a way to pass commit tags to 'emerge' or specify in the ebuild?  Either way once I figure that out I will bisect mesa.

(In reply to comment #5)
> is there a way to pass commit tags to 'emerge' or specify in the ebuild?

The x11 overlay has live ebuilds. Use EGIT_COMMIT to specify a commit to checkout.

http://devmanual.gentoo.org/eclass-reference/git-2.eclass/index.html

(In reply to comment #4)
> But if I downgrade to mesa 7.10.2, I am still using llvm 2.9 and the
> crackberg screensaver works correctly, so that would point to mesa-git
> being the problem for me.  I cannot compile mesa-git without llvm as the
> build process halts and complains that r300 gallium requires llvm to
> build.  There are three gentoo patches that get applied on top of the
> mesa 7.10.2-r1 build, I haven't looked at what they do yet.
> 
> (In reply to comment #2)
> > I have some problem, and i have  ATI RS482 too, but i think it was the fault
> > llvm, with out llvm or < 2.9 , all woks fine, with llvm > 2.8  openarena,
> > urbanterror and some xscreensaver segfault. see
> > https://bugs.freedesktop.org/show_bug.cgi?id=36738
> > I make backtrace with crackberg.

Can you run crackberg with gdb, and show backtrace? Or run openarena with
mesa-git+llvm-2.9.

(In reply to comment #3)
> Can you bisect mesa?

Bisecting lead me to this commit:

b10bff11350014e1bb49b0ce18704fdd66e850c0 is the first bad commit
commit b10bff11350014e1bb49b0ce18704fdd66e850c0
Author: Marek Olšák <maraeo@gmail.com>
Date:   Sat Dec 25 14:39:07 2010 +0100

    r300g: increase the size of upload buffers

On the way here, some of the bisects that failed had varying behaviour.  All of them had abysmal frame rates and the CPU% shot up to 100% on one CPU (only uses 50% prior to this commit).  Some continued to run, others locked up the x server and required an Alt-SysRq-B to reboot.

Created attachment 46696 [details] [review]
possible fix

Could you try this patch?

(In reply to comment #9)
> Created an attachment (id=46696) [details]
> possible fix
> 
> Could you try this patch?

The patch applied to latest mesa-git allows crackberg to run at the expected framerate with the expected cpu% for a few seconds (5-15 seconds), then it segfaults.  The segfault might be caused by a different commit.  Would it be worth bisecting again but applying the possible fix patch above each time before compiling to see if I can find another bad commit?

It would be better to experiment with the patch and try smaller buffer sizes. Please let me know when you find a size which works.

(In reply to comment #11)
> It would be better to experiment with the patch and try smaller buffer sizes.
> Please let me know when you find a size which works.

The current mesa-git value for the R300_MAX_DRAW_VBO_SIZE is 1024 * 1024 and your patch dropped it down to 512 * 1024.  I tried with 64 * 1024 (which is the value that worked before the commit that I bisected above) and crackberg works, the animation is smooth and the cpu usage is 50% on one cpu, but it segfaults after 13-18 seconds.  I really think there is another bug being uncovered here.  I do not know which buffer size to recommend for R300_MAX_DRAW_VBO_SIZE, 512 * 1024 as per your attached patch worked as well as 64 * 1024.  I assume that the value must be a power of 2, or are there some other values to test?  Should I test the values between 64 and 512 for completeness?

(In reply to comment #12)
> (In reply to comment #11)
> > It would be better to experiment with the patch and try smaller buffer sizes.
> > Please let me know when you find a size which works.
> 
> The current mesa-git value for the R300_MAX_DRAW_VBO_SIZE is 1024 * 1024 and
> your patch dropped it down to 512 * 1024.  I tried with 64 * 1024 (which is the
> value that worked before the commit that I bisected above) and crackberg works,
> the animation is smooth and the cpu usage is 50% on one cpu, but it segfaults
> after 13-18 seconds.  I really think there is another bug being uncovered here.
>  I do not know which buffer size to recommend for R300_MAX_DRAW_VBO_SIZE, 512 *
> 1024 as per your attached patch worked as well as 64 * 1024.  I assume that the
> value must be a power of 2, or are there some other values to test?  Should I
> test the values between 64 and 512 for completeness?

Disregard my last comment above, I was totally incorrect.  A value for R300_MAX_DRAW_VBO_SIZE of 32 * 1024 fixed crackberg completely for me.  I will attach the working patch as 0003-r300g-allocate-smaller-upload-buffers.patch.  Thanks Marek.

Created attachment 46763 [details] [review]
fix for crackberg performance and segfaulting on rs482

(In reply to comment #14)
> Created an attachment (id=46763) [details]
> fix for crackberg performance and segfaulting on rs482

Hmmmm, the lateset patch with a value of 32 * 1024 fixes crackberg but now antmaze gives me:
radeon: The kernel rejected CS, see dmesg for more information.

and dmesg says:
radeon 0000:01:05.0: (PW 2) Vertex array 0 need 8436 dwords have 8192 dwords
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
radeon 0000:01:05.0: (PW 2) Vertex array 0 need 8436 dwords have 8192 dwords
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
radeon 0000:01:05.0: (PW 2) Vertex array 0 need 8436 dwords have 8192 dwords
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
radeon 0000:01:05.0: (PW 2) Vertex array 0 need 8436 dwords have 8192 dwords
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
radeon 0000:01:05.0: (PW 2) Vertex array 0 need 8436 dwords have 8192 dwords
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
radeon 0000:01:05.0: (PW 2) Vertex array 0 need 8436 dwords have 8192 dwords
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
antmaze[13259]: segfault at 4 ip b5b57000 sp bfd14fcc error 6

I will play with the values some more.

It's possible the bisection went wrong and the upload buffer size has nothing to do with this issue.

I just instaled xscreensaver and run crackberg on rv350 / radeon 9600 agp.Normal memory usage nothing special.No warnings in logs. Animation works without any artefacts or screen flashing.