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. Aborted " 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! kind regards jakub
> 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....!) 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
well, 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: http://dri.freedesktop.org/wiki/Building#head-b966b34cdcffecd080a197df26472e5ae2efe516 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... regards jakub
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): Backtrace: 0: /usr/bin/X(xorg_backtrace+0x3b) [0x8133d7b] 1: /usr/bin/X(xf86SigHandler+0x55) [0x80c7d35] 2: [0xf74400] 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: http://cgit.freedesktop.org/mesa/mesa/commit/?id=77506dac8e81e9548a7e9680ce367175fe5747af 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] fix attempt 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: http://cgit.freedesktop.org/mesa/mesa/commit/?h=mesa_7_6_branch&id=e4c5fe52c99bdf651aafa1569d9cf901891004d8 http://cgit.freedesktop.org/mesa/mesa/commit/?h=mesa_7_7_branch&id=92c6a26a8a0f6ce540fe7c9681fb9a30b0da9e5f
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.