If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

(R500, radeon, x64) games segfaulting

Hey folks, i'm not sure if this is the right forum to post, but my research has led me to believe that. If it should turn out that this i just forgot to switch on some obscure options, or it is actually the games' bugs, then feel free to move this thread.
I'm currently running Ubuntu Jaunty with stock kernel (2.6.28-15, x64) and opensource radeon drivers & graphics stack from the xorg-edgers ppa, on a 64-bit system with a Radeon X1600 w/ 256 MB RAM.
Openarena, compiz and the demos of ballistics and Postal 2 work like a charm, but the game that brought me to the whole thougt of playing on linux is hanging
When i try to start the demo version of LGP's X2 port, i see the loading screen, then it turns blank, i hear the sounds of LGPs "intro movie", then silence and blank screen for 1-4 seconds, and then the game segfaults with a message like this:

.
the syslogs also show nothing suspicious. Results are the same with stock graphics stack.
I think i have installed all the necessary libraries for running 32-bit apps on 64-bit systems, as well as all the old libraries required by LGPs installers (the script getlibs was a great help).
However, the demo runs fine (well, at slideshow-speed, but playable) on my EEE pc 4G, which has its integrated Intel graphic chip, an even older kernel and a 32-bit system.

My questions now are:
1. From my limited knowledge, a segfault often points to a memory problem. Could a custom compiled 2.6.31 kernel with enabled GEM/TTM bring help?
2. Could this segfault be a result of some animosity between 32-bit app and 64-bit system? i have 8 GB RAM installed, so perhaps there lies a source of trouble.
3. Could it be that the drivers' OpenGL implementation (somewhere at OpenGL v. 1.4 IIRC) just not yet fulfils the games' needs?
4. Might there be some arcane option in the xorg.conf or elsewhere, for direct rendering, shadowfb or something else? currently my xorg.conf has no customized entries.

I'm guessing here too, but in the "Graphics Test" portion of your second quote it looks like the "normal" libGL is being skipped in favor of one in lib32. What I'm not sure is if that means you're skipping the nice new (64-bit) mesa you installed from the edgers ppa and picking up an old 32-bit mesa, or if the ppa gave you a 32-bit lib as well and the libGL.so files being skipped are old junk from a previous installation.

My guess is the first option, ie that this has something to do with 64 vs 32 bit.

So this is the lib that xorg-edgers ships and which should be used on a 64-bit system. I have no experience with 64 bit and I am not sure what should happen when you run 32-bit apps on them though. Where is the other lib coming from?

Code:

dpkg -S /usr/lib32/libGL.so.1

For your question (1) about the kernel: Why don't you just install the newest Karmic kernel? You can keep the old, and choose between them at boot.

Hey folks, i'm not sure if this is the right forum to post, but my research has led me to believe that. If it should turn out that this i just forgot to switch on some obscure options, or it is actually the games' bugs, then feel free to move this thread.
I'm currently running Ubuntu Jaunty with stock kernel (2.6.28-15, x64) and opensource radeon drivers & graphics stack from the xorg-edgers ppa, on a 64-bit system with a Radeon X1600 w/ 256 MB RAM.
Openarena, compiz and the demos of ballistics and Postal 2 work like a charm, but the game that brought me to the whole thougt of playing on linux is hanging
When i try to start the demo version of LGP's X2 port, i see the loading screen, then it turns blank, i hear the sounds of LGPs "intro movie", then silence and blank screen for 1-4 seconds, and then the game segfaults with a message like this:

Second, /usr/lib32/dri/r300_dri.so (and/or /usr/lib32/libGL.so.1) might be just to old/incompatible with rest of the system.
Solution is to install newer one.
Less likely, as library looks(from testtool output) quiet new, but still possible.

Third, radeon.ko doesn't support compat ioctl(no 32bit ioctls for 32bit binaries on 64bit kernel) while KMS is enabled. I have only found It on KMS-enabled kernels(2.6.31) eg. KMS must be running. Like I said only on 2.6.31.

And many more.

Easiest way to find source of you problem is to get 32bit version of glxinfo and run it:
LIBGL_DEBUG=verbose glxinfo 1>/dev/null
Output should include only debug info.
You might also want to try LIBGL_DRIVERS_PATH trick.
Comparing full output of 32bit glxinfo with 64bit one might be also useful.

Originally Posted by wirrbeltier

the syslogs also show nothing suspicious. Results are the same with stock graphics stack.
I think i have installed all the necessary libraries for running 32-bit apps on 64-bit systems, as well as all the old libraries required by LGPs installers (the script getlibs was a great help).

getlibs is not a tool that you want to use.
I bet Ubuntu have a tool to install 32bit libraries alongside 64bit ones(debian have). Use it.

Originally Posted by wirrbeltier

My questions now are:
1. From my limited knowledge, a segfault often points to a memory problem. Could a custom compiled 2.6.31 kernel with enabled GEM/TTM bring help?

From my personal experience if you want to run 32bit opengl binaries on 64bit kernel, 2.6.31 kernel with GEM/TTM/KMS enabled, is not what you looking for.

Originally Posted by wirrbeltier

2. Could this segfault be a result of some animosity between 32-bit app and 64-bit system? i have 8 GB RAM installed, so perhaps there lies a source of trouble.

I don't think so.

Originally Posted by wirrbeltier

3. Could it be that the drivers' OpenGL implementation (somewhere at OpenGL v. 1.4 IIRC) just not yet fulfils the games' needs?

With git mesa(maybe 1.5 OpenGL dri1) I was able not only to start game but also fly in ship a bit.
I didn't tested it more due to lack of time.

Originally Posted by wirrbeltier

4. Might there be some arcane option in the xorg.conf or elsewhere, for direct rendering, shadowfb or something else? currently my xorg.conf has no customized entries.

Right, so tormod & folks should now go on packaging new versions of ia32-libgl1-mesa-* too?

Can the ia32-libs-tools package be of help?

Description: Tools for converting i386 debs for amd64 and ia64
On amd64 and ia64 the kernel is capable of executing i386
binaries. For that to work with dynamically linked binaries the
required 32bit libraries need to be available as well. This package
contains tools to convert native i386 binary packages for use under
amd64 or ia64.

Easiest way to find source of you problem is to get 32bit version of glxinfo and run it:
LIBGL_DEBUG=verbose glxinfo 1>/dev/null
Output should include only debug info.
You might also want to try LIBGL_DRIVERS_PATH trick.
Comparing full output of 32bit glxinfo with 64bit one might be also useful.

I'm having the same issue with 32-bit programs using Ubuntu64 9.10 (I'm not using any 32-bit 3D programs, so the issue is purely academic right now). On Ubuntu, a lot of the Debian ia32 packages are combined into 'ia32-libs' package. I have this package installed and it provides 32-bit versions of mesa libGL and the DRI drivers (the DRI drivers are installed in /usr/lib32/dri).

Even with the driver path trick, I cannot get 32-bit glxinfo to use direct rendering, and it seems like glxinfo doesn't even look in /usr/lib32:

It's still trying to load the 64bit libraries for you... Also the original issue was with r500 and is unrelated to yours. Also you must be doing the driver path wrong considering where it's looking for the driver.

I'm having the same issue with 32-bit programs using Ubuntu64 9.10 (I'm not using any 32-bit 3D programs, so the issue is purely academic right now). On Ubuntu, a lot of the Debian ia32 packages are combined into 'ia32-libs' package. I have this package installed and it provides 32-bit versions of mesa libGL and the DRI drivers (the DRI drivers are installed in /usr/lib32/dri).

Even with the driver path trick, I cannot get 32-bit glxinfo to use direct rendering, and it seems like glxinfo doesn't even look in /usr/lib32: