Supertuxkart doesn't start after having built latest mesa tree (worked before - on mesa 7.4)
Couldnt find out if i have made some mistake compiling since the guide for compiling isnt too userfriendly, especially for newbies like me...
and i think ubuntu 7.04 isnt considerd a NEW operating system anymore.....
thats what shows up in the terminal when starting over it:
supertuxkart: radeon_lock.c:65: radeonGetLock: Assertion `drawable != ((void *)0)' failed.
besides, when compiling: do i need the r300 or just the radeon driver compiled?
whats the difference etc (there really is no bloody explanation on the net....!)
hoping i could point something out that could have any kind of importance XD
thx for all the work done yet!
> besides, when compiling: do i need the r300 or just the radeon driver compiled?
> whats the difference etc (there really is no bloody explanation on the
You usually only need the driver for your card:
- radeon driver supports R100 cards
- r200 driver supports R200 cards
- r300 driver supports R300-R400-R500-RS690 cards
$ glxinfo | grep render
will give you information on your card type.
Ubuntu 7.04 is a bit old, it would be best if you are able to test with a newer version, since the bug may be also caused by other components, e.g. drm radeon module found in kernel.
thx for the reply
i KNOW its not new, and i didnt say i was using it, im running Jaunty, with 2.6.30 kernel (amd 64bit). what i was pointing at was that the documentation on the mesa site was a bit hard to understand and severely outdated since IT said Ubuntu 7.4 were a new operating system.
i got a radeon 9600 pro (sapphire atlantis 128MB and so on...)
glxinfo grep rander says:
direct rendering: Yes
OpenGL renderer string: Mesa DRI R300 (RV350 4150) 20090101 AGP 8x TCL
so its just the r300 then? (no "radeon" driver needed then..?)
i'll try to compile it again, this time with the aid of a friend of mine who knows things better and report again.
or maybe you want to see the compiling options or the compiled drivers themselves .... or i dunno
after my friend has come and compiled the whole thing again (mesa) it worked, althought the compilation was a little strange.
thats the page i'm talking about:
its a nice to follow instruction, although heavily outdated and thus not really guaranteeing a proper installation
by the way i got into this mess by trying to get mesa 7.5 running, so after having compiled and having done "sudo make install" glxinfo said it was still using mesa 7.4
then i tried the "building" alla see-the-site-above...
Mass version move, cvs -> git
I am also having this problem with boswar game when exiting the game with both current master and mesa_7_6_branch on 32 bit Ubuntu Linux 9.10 with no KMS. This is my card:
GL_RENDERER = Mesa DRI R300 (RV530 71C5) 20090101 x86/MMX/SSE2 TCL
How to reproduce:
- run boswars (the game is packaged for Ubuntu)
- in the 'Video' configuration dialog of the 'Options' menu,
tick "Use OpenGl"
- restart the game.
- exit, I get:
Thanks for playing Bos Wars.
boswars: radeon_lock.c:65: radeonGetLock: Assertion `drawable != ((void *)0)' failed.
Aborted (core dump creato)
I also tried to run it under gdb, however the games freezes and I cannot take a backtrace; if I switch to VT 2-3 times X crashes (note that I am not using compiz):
0: /usr/bin/X(xorg_backtrace+0x3b) [0x8133d7b]
1: /usr/bin/X(xf86SigHandler+0x55) [0x80c7d35]
3: /usr/bin/X [0x80f9a00]
4: /usr/bin/X(xf86Wakeup+0x454) [0x80c85b4]
5: /usr/bin/X(WakeupHandler+0x52) [0x8091642]
6: /usr/bin/X(WaitForSomething+0x1aa) [0x81317ba]
7: /usr/bin/X(Dispatch+0x98) [0x808ceb8]
8: /usr/bin/X(main+0x395) [0x8072515]
9: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0x14fb56]
10: /usr/bin/X [0x80719c1]
Dave Airlie please read this.
I noticed that things went worse after the merge of the radeon-texrewrite-clean branch: also the wine game Panzers II starts to assert this way. I bisected to this commit: http://cgit.freedesktop.org/~osiris/mesa/commit/?h=radeon-texrewrite-clean&id=aa195611586cdfb21bb1707b12b16e461a92d42e
but probably it only triggered this same bug.
So I tried bisecting master for searching where the assertion first appeared. Surprisingly I got this commit:
Indeed, after reverting this commit from the 7.7 branch both Panzers II and boswars (see my previous comment for a way to reproduce this) started to work fine again. Dave, could you take a look at it?
can you ssh in and run it under gdb?
you can't run it under gdb with DRI1 on the same server
a backtrace when the assert hits would help a lot
Created attachment 31461 [details] [review]
Please try the attached patch.
(In reply to comment #8)
> Created an attachment (id=31461) [details]
> fix attempt
> Please try the attached patch.
As discussed on #radeon attached patch works fine. Leaving open up until the patch is merged.
The fix is now on 7.6 and 7.7 branches.
Jakub Orlowski, could you verify it's fixed also for you?
im sry, it was fixed some time ago, it seemed that the mesa 7.6 wasnt compiled properly, due to my noobness and a compilaion guide that was...... havily oudated, but everythings fine for me
Just adding the commits for reference: