Unable to run linux 3d apps

[arundel]

Hi there.

I've had this issue with driver versions 171.06, 173.08 and 173.14.05. Whenever I try to run a linux application that uses 3d, the application crashes. Here are some examples:

linux-quake4:

Initializing SDL subsystem
Loading GL driver 'libGL.so.1' through SDL
Initializing SDL subsystem
Loading GL driver 'libGL.so.1' through SDL
Fatal Error: Unable to initialize OpenGL
--------------- BSE Shutdown ----------------
---------------------------------------------
idRenderSystem::Shutdown()
Sys_Error: Unable to initialize OpenGL

linux-doom3 (app remains running though and must be killed by hand):

Setup X display connection
dlopen(libGL.so.1)
Illegal instruction: 4

linux-ut2004 produces no output at all and simply hangs after a few seconds of hdd activity. the app can be ended with ctrl+c giving me the following output:

CTRL-C before main loop ... forcing exit.

i'm running emulators/linux_base-f8 and compat.linux.osrelease is set to "2.6.20". However switching to an older linux_base port doesn't solve the issue.

and to be sure the linux libraries are installed:

[arundel@linux - 04:28 pm] pwd
/usr/home/arundel/NVIDIA-FreeBSD-x86-173.14.05/obj/linux
[arundel@linux - 04:28 pm] for i in *; do diff -s $i /compat/linux/usr/lib/$i; done
Files libGL.so.173.14.05 and /compat/linux/usr/lib/libGL.so.173.14.05 are identical
Files libGLcore.so.173.14.05 and /compat/linux/usr/lib/libGLcore.so.173.14.05 are identical
diff: /compat/linux/usr/lib/libcuda.so.173.14.05: No such file or directory
diff: /compat/linux/usr/lib/libnvidia-cfg.so.173.14.05: No such file or directory
Files libnvidia-tls.so.173.14.05 and /compat/linux/usr/lib/libnvidia-tls.so.173.14.05 are identical

I'm running FreeBSD 7.0-STABLE #0: Mon May 26 14:11:41 CEST 2008 and my graphic card is a GeForce 9600 GT. I searched a bit on google, but all I could find in connection with my problem were linux users who were running X in 16bit unstead of 24bit. I double checked by Xorg.conf and it's set to 24bit. I'm having no problem with the native freebsd quake3 executable e.g. which runs great at nearly 650 fps in timedemo mode.

I send in a bug report via mail a month ago or so, but since the issue still remains I'll give it another shot.

Cheers.

UPDATE:

I did some more research and came upon a few more details concerning my problem. First of all the error message quake4 produces is due to the fact that the linux GL libraries couldn't be found. Unfortunately id hasn't really been good in putting proper error messages into their games. So "Fatal Error: Unable to initialize OpenGL" in this case means that the libraries couldn't be found and quake4 is trying to make use of the freebsd GL libraries which obviously won't work. The reason the linux GL libraries couldn't be found is, because all id games I tested so far (except linux-doom3) have a hardcoded RPATH which points to "/usr/local/lib". Since the nvidia drivers get installed into /compat/linux/usr/lib id games won't find them. I tested this with the linux-enemy-territory-quake-wars demo an got the following error message (thanks to id for finally improving their error messages):

WARNING: SDL_GL_LoadLibrary libGL.so.1 failed: Failed loading libGL.so.1: /usr/local/lib/libGL.so.1: ELF file OS ABI invalid

So what i did was to create softlinks for the GL libraries pointing from /compat/linux/usr/lib/* to /compat/linux/usr/local/lib/. However I don't quite understand why if I re-install the nvidia drivers the links in /compat/linux/usr/local/ are being removed. What's the purpose of this?

Well. What happend after I performed the steps I described above was that all id games now output the same error message doom3 does. I checked a bit around and and signal 4 seems to be caused by missing SSE, SSE2 and SSE3 support. Now that's odd because I'm pretty sure my CPU supports all of those features:

taken from dmegs:

CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (1800.01-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x6fd Stepping = 13
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE ,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH, DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Features2=0xe39d<SSE3,RSVD2,MON,DS_CPL,EST,TM2,SSS E3,CX16,xTPR,PDCM>
AMD Features=0x20100000<NX,LM>
AMD Features2=0x1<LAHF>
Cores per package: 2

However I think I once read that freebsd itself doesn't support SSE3 yet. Well...Im out of ideas. ;)

[Fusselbaer]

Hello,

gigiita wrote this about nvidia-driver and FreeBSD linuxator:
http://www.nvnews.net/vbulletin/showthread.php?t=105545

In BSDGroup wie have spoken (in german language) about that too:
https://forum.bsdgroup.de/showthread...=nvidia-driver
OliverHerold wrote he can use the linuxator
with compat.linux.osrelease: 2.4.2 and linux_base-fc-4_10 like in FreeBSD 6.x.

But compat.linux.osrelease: 2.6.16 and linux_base-fc6
is the new default in FreeBSD 7 and nvidia-driver stopp work
in FreeBSD 7 linuxator with
compat.linux.osrelease: 2.6.16 and linux_base-fc6.


Greetings, Fusselbaer

[arundel]

oh dear. i didn't realise the linuxulator was that broken.

maybe somebody running the HEAD branch could test the driver and see if linux apps work. i had a quick look at the linuxulator sources using webcvs and they comitted quite a lot of changes recently to it.

i also did a bit of debugging and at least doom3 dies after issueing a linux_sys_futex syscall and that's exactly the syscall the recent commits to HEAD are dealing with.

cheers.

[Fusselbaer]

@arundel:

Oh no,
i think it's not the linuxator, that is broken,
FreeBSD 7 new linuxator seems only incompatible
with linux part of nvidia-driver, or vice versa.
I make my little experiments and put by hand
the linux_dri in place of the nvidia-driver linux libs
and the 3D linux games in FreeBSD 7 linuxator start,
not realy "running", but i can start linux ut2004 3D game.
ut2004 works realy slow with linux_dri, not realy playable.

The libs from nvidia-driver linux part are:

/usr/compat/linux/usr/lib/libGL.so.1

wich is a link to:

/usr/compat/linux/usr/lib/libGL.so.100.14.23

(the version may be change, this version is from my old post at BSDGroup.de in November 2007)


Greetings, Fusselbaer

[arundel]

Thanks for the hint. After installing the linux_dri port I was able to actually play ut2004. It's very slow even in 320x200 but at least it works.

id games however complain about a missing linux version of libdrm.

I still think the problem is with the linuxulator though. I downloaded the linux drivers and compared the libraries to the ones the freebsd driver installs into /compat/linux/lib. They are the same. So it's up to the linuxulator to properly map the linux syscalls to their counterparts in freebsd. And at least the linux_sys_futex syscall is either not implemented or isn't doing what it's supposed to do. Check out this warning I got while running ut2004:

kernel: linux_sys_futex: unknown op 734717281

I'll try rebuilding the linuxulator with debugging. Maybe that reveals during which syscall the id games crash.

[arundel]

Ok. After recompiling the linuxulator with debugging support I found the exact position where all the id apps crash:

http://fxr.watson.org/fxr/source/i38...=FREEBSD7#L372

372         if (copyout(&frame, fp, sizeof(frame)) != 0) {
373                 /*
374                  * Process has trashed its stack; give it an illegal
375                  * instruction to halt it in its tracks.
376                  */
377 #ifdef DEBUG
378                 if (ldebug(rt_sendsig))
379                         printf(LMSG("rt_sendsig: bad stack %p, oonstack=%x"),
380                             fp, oonstack);
381 #endif
382                 PROC_LOCK(p);
383                 sigexit(td, SIGILL);
384         }

The following debug message is being output ~ 1/4 of a million times. After that the stack is trashed and the app receives an illegal instruction (SIGILL = 4) by the linuxulator in order to let it crash.

rt_sendsig(0x829f860, 11, 0xc6172138, 1)
rt_sendsig flags: 0x2, sp: 0, ss: 0x0, mask: 0x0

and finally:

rt_sendsig: bad stack 0xbbbfffa0, oonstack=0

There seems to be some kind of loop in all the id games which runs until it hits a certan condition, but that condition never occurs. Maybe some function in the linuxulator is returning values which differ from the actual linux function. I don't know

It would really be interesting to see what happens on a system that's running CURRENT.

cheers.

[gigiita]

I will try it.
By the way, the linux version of glxinfo should say "direct rendering: no" Did you check it?

[arundel]

if i try to run linux-glxinfo it coredumps.

[gigiita]

mm...mm..
I cannot compile a CURRENT system. Odd errors in make world....
At the moment i can't try anything. Sorry.