status of linux games support

[arundel]

hi there.

does anybody know of a way to get linux games to work? i'm running HEAD (freebsd 8). so the linuxulator code should be the cutting edge. but still all linux games crash with the freebsd NVIDIA drivers.

the only way to run linux games is to install graphics/linux_dri. the port also installs a linux version of (glx)gears. if i anstall the NVIDIA drivers afterwards thus overwriting e.g. the libGL version installed by the linux_dri port (glx)gears segfaults.

what's the actual problem? is the linuxulator still missing some linux syscalls or are some syscalls buggy? it can't be the linux libraries, because they are exactly the same as the one's that ship with the linux NVIDIA drivers.

cheers.
alex

p.s.: oh...and here's yet another issue. the linux drivers get installed into usr/lib. however all of the id software games have a hardcoded path to libGL.so.1 encoded which points to usr/local/lib. right now the NVIDIA Makefile checks a few locations (including usr/local/lib) for files like libGL.so.1 and deletes/unlinks them. probably because it's better to be sure the files only exist in one location and all the libs are the actual NVIDIA version. it would be nice however if the installer could create symlinks from usr/lib to /usr/local/lib. that way the id software games have a chance to find the NVIDIA libraries.

[zander]

Which driver release are you using (please generate and attach an nvidia-bug-report.log file)? The NVIDIA FreeBSD graphics driver's Linux ABI compatibility support as such should work, at least there're no fundamental problems with it that I'm aware of. That said, there've been reports of problems (application crashes, specifically) with FreeBSD 8.0-CURRENT. The Linux libraries (libGL.so, etc.) should be installed to /compat/linux/usr/lib, not /usr/lib.

[summoner]

I'm also getting problems with Linux games. I've tested Linux acroread8, and this works, but Linux binaries which attempt to bind libGL crash and burn.

[arundel]

Which driver release are you using (please generate and attach an nvidia-bug-report.log file)? The NVIDIA FreeBSD graphics driver's Linux ABI compatibility support as such should work, at least there're no fundamental problems with it that I'm aware of. That said, there've been reports of problems (application crashes, specifically) with FreeBSD 8.0-CURRENT. The Linux libraries (libGL.so, etc.) should be installed to /compat/linux/usr/lib, not /usr/lib.

oh sorry. i guess i forgot to say that when i wrote /usr/lib i actually meant /compat/linux/usr/lib. my bad.

i installed 180.37 a few minutes ago. what happens when i try to run quake4 is that i get the following error message:

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

so it seems quake4 looks for libGL.so.1 in /usr/local/lib. the linuxulator translates that path to /compat/linux/usr/local/lib. since there's no libGL.so.1 in that path the linuxulator then looks in the actual path (/usr/local/lib). there it finds the freebsd version of libGL.so.1. however since that's not the one quake4 needs it outputs the error message i've posted above.

now...what i've done to resolve that issue is to copy all the nvidia libraries from /compat/linux/usr/lib to compat/linux/usr/local/lib. that's why i proposed that the NVIDIA driver installation not only installs the linux libraries to /compat/linux/usr/lib, but also creates symlinks to /compat/linux/usr/local/lib, because almost all the id software games look for the libGL.so.1 in a hardcoded path (being /usr/local/lib which get's wrapped by the linuxulator to /compat/linux/usr/local/lib).

when i run quake4 again i get this error message:

--------------- R_InitOpenGL ----------------
Initializing SDL subsystem
Loading GL driver 'libGL.so.1' through SDL
signal caught: Segmentation fault
si_code 1
Trying to exit gracefully..
--------------- BSE Shutdown ----------------
---------------------------------------------
WARNING: rvServerScanGUI::Clear() - invalid scanGUI

idRenderSystem::Shutdown()

^CKilled: 9

i also tried running unreal tournament 2004 which doesn't look for libGL.so.1 in a hardcoded path. however the game also crashes with this error message (written to UT2004.log):

Log: Log file open, Mon Mar 9 17:08:32 2009
Init: Name subsystem initialized
Init: Version: 3369 (128.29)
Init: Compiled: Dec 16 2005 13:23:47
Init: Command line:
Init: (This is Linux patch version 3369.2)
Init: Character set: Unicode
Init: Base directory: /usr/local/games/ut2004/System/
Init: Ini:UT2004.ini UserIni:User.ini
Init: Build label: UT2004 Build UT2004_Build_[2005-11-23_16.22]
Init: Object subsystem initialized
Log: Initializing OpenGLDrv...
Log: binding libGL.so.1
Log:
Developer Backtrace:
Log: [ 1] ./ut2004-bin [0x874bdd9]
Log: [ 2] [0xbfbfffbb]
Log: Unreal Call Stack: UOpenGLRenderDevice::Init <- UGameEngine::Init <- InitEngine
Exit: Exiting.
Log: FileManager: Reading 0 GByte 33 MByte 783 KByte 22 Bytes from HD took 11.556140 seconds (11.556140 reading, 0.000000 seeking).
Log: FileManager: 0.000000 seconds spent with misc. duties
Uninitialized: Name subsystem shut down
Uninitialized: Allocation checking disabled
Uninitialized: Log file closed, Mon Mar 9 17:08:48 2009


cheers.

[zander]

The libGL.so.1 load failure looks like a library load path setup problem, /usr/lib is the correct installation for the OpenGL libraries per the Linux OpenGL ABI and typically works fine. As to the segmentation fault, chances are you're experiencing the problem(s) with FreeBSD 8.0-CURRENT I referred to earlier. Unfortunately, I haven't had a chance to try reproducing this problem, yet.

[Harvey Pooka]

oh sorry. i guess i forgot to say that when i wrote /usr/lib i actually meant /compat/linux/usr/lib. my bad.

i installed 180.37 a few minutes ago. what happens when i try to run quake4 is that i get the following error message:

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

so it seems quake4 looks for libGL.so.1 in /usr/local/lib. the linuxulator translates that path to /compat/linux/usr/local/lib. since there's no libGL.so.1 in that path the linuxulator then looks in the actual path (/usr/local/lib). there it finds the freebsd version of libGL.so.1. however since that's not the one quake4 needs it outputs the error message i've posted above.

Although it probably does not fix the segmentation fault, you can try the patching I added to the linux-ut port (http://www.freebsd.org/cgi/cvsweb.cgi/ports/games/linux-ut/Makefile?rev=1.7) to remove the /usr/local/lib that is hard-coded into the binary. Look for the section concerning "Remove /usr/local from ut-bin lib search path" in the Makefile.

I still get a segmentation fault, but at least the program is dying on the correct library. ;)

[zebdits]

i installed 180.37 a few minutes ago. what happens when i try to run quake4 is that i get the following error message:

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

when i run quake4 again i get this error message:

--------------- R_InitOpenGL ----------------
Initializing SDL subsystem
Loading GL driver 'libGL.so.1' through SDL
signal caught: Segmentation fault
si_code 1
Trying to exit gracefully..
--------------- BSE Shutdown ----------------
---------------------------------------------
WARNING: rvServerScanGUI::Clear() - invalid scanGUI

idRenderSystem::Shutdown()

^CKilled: 9

These same problems was fixed by a friend of mine and described in this pr more than an year ago
http://www.freebsd.org/cgi/query-pr.cgi?pr=118230
Unfortunately no one is taking care about that pr.
The fix worked for me too.
I also have linux-doom3, linux-enemyterritory (+ various mods), and rtcw.
None of the above required the manual fix.
And IMO they work better then in windows (way stable and faster) and linux (little faster+better audio)!

[rnejdl]

And on FreeBSD 7 I don't even have that directory

[tethys]:/usr/compat/linux/usr> ls
X11R6/ doc/ games/ kerberos/ libexec/ share/ tmp@
bin/ etc/ include/ lib/ sbin/ src/
[tethys]:/usr/compat/linux/usr>

All of this is in /usr/compat/linux/usr/lib as it should be with no symlinks needed:

[tethys]:/usr/compat/linux/usr/lib> ls | grep libGL
libGL.so.180.37
libGL.so.1@
libGLcore.so.180.37
libGLcore.so.1@
[tethys]:/usr/compat/linux/usr/lib>

I am running :

linux_base-fc-4_14

and

compat.linux.osrelease: 2.6.16

Rusty Nejdl

[zebdits]

And on FreeBSD 7I am running :

linux_base-fc-4_14

and

compat.linux.osrelease: 2.6.16

Rusty Nejdl

You should move to emulators/linux_base-f8
http://www.freebsd.org/cgi/cvsweb.cgi/ports/UPDATING.diff?r1=1.127;r2=1.128;f=h

[arundel]

These same problems was fixed by a friend of mine and described in this pr more than an year ago
http://www.freebsd.org/cgi/query-pr.cgi?pr=118230
Unfortunately no one is taking care about that pr.
The fix worked for me too.
I also have linux-doom3, linux-enemyterritory (+ various mods), and rtcw.
None of the above required the manual fix.
And IMO they work better then in windows (way stable and faster) and linux (little faster+better audio)!

i followed the description in the PR, yet quake4 still crashes with the same error message.

[arundel]

here's a little script to set up a few symlinks in order for id software games to find the required libraries:

#!/bin/sh
cd /compat/linux/usr/local/lib/
ln -is ../../lib/libGL.so.1
ln -is ../../lib/libGLcore.so.1
ln -is ../../lib/libnvidia-tls.so.1

this however doesn't solve the issue which let's all linux 3d apps crash. maybe the freebsd-emulation mailinglist can help to identify the problem.

[arundel]

here's some more information concerning the problem. i think the reason the linux apps crash is due to the linux_futex syscall not being fully supported. i ran both ut2004 and quake4 using ktrace. these are the results.

ut2004:
...
1180 ut2004-bin RET close 0
1180 ut2004-bin CALL linux_brk(0xae5c000)
1180 ut2004-bin RET linux_brk 182829056/0xae5c000
1180 ut2004-bin CALL linux_getpid
1180 ut2004-bin RET linux_getpid 1180/0x49c
1180 ut2004-bin CALL linux_getpid
1180 ut2004-bin RET linux_getpid 1180/0x49c
1180 ut2004-bin CALL linux_getpid
1180 ut2004-bin RET linux_getpid 1180/0x49c
1180 ut2004-bin CALL linux_sys_futex(0x2b406e30,0x81,0x7fffffff,0,0x49c ,0x7)
1180 ut2004-bin RET linux_sys_futex 1
1180 ut2004-bin PSIG SIGSEGV caught handler=0x874bd50 mask=0x0 code=0x0
1180 ut2004-bin CALL linux_fstat64(0x1,0xbfbfa9e8,0x28fe8ff4)
1180 ut2004-bin UNKNOWN(8) 1180 ut2004-bin RET linux_fstat64 0
1180 ut2004-bin CALL linux_mmap2(0,0x1000,0x3,0x22,0xffffffff,0)
1180 ut2004-bin RET linux_mmap2 688971776/0x2910e000
1180 ut2004-bin CALL write(0x1,0x2910e000,0x25)
1180 ut2004-bin GIO fd 1 wrote 37 bytes
"Signal: SIGSEGV [segmentation fault]
"
1180 ut2004-bin RET write 37/0x25
1180 ut2004-bin CALL write(0x1,0x2910e000,0xa)
1180 ut2004-bin GIO fd 1 wrote 10 bytes
"Aborting.
"
1180 ut2004-bin RET write 10/0xa
1180 ut2004-bin CALL write(0x1,0x2910e000,0x1)
1180 ut2004-bin GIO fd 1 wrote 1 byte
"
"
1180 ut2004-bin RET write 1
1180 ut2004-bin CALL write(0x1,0x2910e000,0x1)
1180 ut2004-bin GIO fd 1 wrote 1 byte
"
"
1180 ut2004-bin RET write 1
1180 ut2004-bin CALL write(0x1,0x2910e000,0x31)
1180 ut2004-bin GIO fd 1 wrote 49 bytes
"Crash information will be saved to your logfile.
"
1180 ut2004-bin RET write 49/0x31
1180 ut2004-bin CALL linux_sys_futex(0x28feba34,0x81,0x7fffffff,0,0xbfb fab14,0xbfbfaaec)
1180 ut2004-bin RET linux_sys_futex 1
1180 ut2004-bin CALL linux_sys_futex(0x28e8eb48,0x81,0x7fffffff,0,0xbfb faa30,0xbfbfa93c)
1180 ut2004-bin RET linux_sys_futex 1
1180 ut2004-bin CALL write(0x4,0x937c3c8,0xc)
...

and quake4:
...
1285 quake4.x86 RET close 0
1285 quake4.x86 CALL linux_getpid
1285 quake4.x86 RET linux_getpid 1285/0x505
1285 quake4.x86 CALL linux_getpid
1285 quake4.x86 RET linux_getpid 1285/0x505
1285 quake4.x86 CALL linux_getpid
1285 quake4.x86 RET linux_getpid 1285/0x505
1285 quake4.x86 CALL linux_sys_futex(0x2dbece30,0x81,0x7fffffff,0,0x505 ,0x7)
1285 quake4.x86 RET linux_sys_futex 1
1285 quake4.x86 PSIG SIGSEGV caught handler=0x8254b10 mask=0x0 code=0x0
1285 quake4.x86 CALL linux_sys_futex(0x286cd620,0x81,0x7fffffff,0,0x505 ,0xbfbfc51c)
1285 quake4.x86 RET linux_sys_futex 1
1285 quake4.x86 CALL write(0x1,0x283dd000,0x22)
1285 quake4.x86 GIO fd 1 wrote 34 bytes
"signal caught: Segmentation fault
"
1285 quake4.x86 RET write 34/0x22
1285 quake4.x86 CALL write(0x1,0x283dd000,0xa)
1285 quake4.x86 GIO fd 1 wrote 10 bytes
"si_code 1
"
1285 quake4.x86 RET write 10/0xa
1285 quake4.x86 CALL write(0x1,0x283dd000,0x1c)
1285 quake4.x86 GIO fd 1 wrote 28 bytes
"Trying to exit gracefully..
"
1285 quake4.x86 RET write 28/0x1c
1285 quake4.x86 CALL write(0x1,0x283dd000,0x2e)
1285 quake4.x86 GIO fd 1 wrote 46 bytes
"--------------- BSE Shutdown ----------------
"
1285 quake4.x86 RET write 46/0x2e
1285 quake4.x86 CALL write(0x1,0x283dd000,0x2e)
1285 quake4.x86 GIO fd 1 wrote 46 bytes
"---------------------------------------------
"
1285 quake4.x86 RET write 46/0x2e
1285 quake4.x86 CALL write(0x1,0x283dd000,0x35)
1285 quake4.x86 GIO fd 1 wrote 53 bytes
"WARNING: rvServerScanGUI::Clear() - invalid scanGUI

"
1285 quake4.x86 RET write 53/0x35
1285 quake4.x86 CALL munmap(0x2d0ee000,0x101000)
1285 quake4.x86 RET munmap 0
1285 quake4.x86 CALL munmap(0x2d1ef000,0x101000)
...

there's a patch updating the linux futex code here: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=0+0+archive/2008/freebsd-emulation/20081228.freebsd-emulation

unfortunately it doesn't apply cleanly to CURRENT, but if you're running STABLE you might want to give it a try and see if linux 3d apps still crash after applying the patch.

cheers.

[zebdits]

i followed the description in the PR, yet quake4 still crashes with the same error message.I've tried it again, as I thought that it can be working no more.
I've literally followed the pr, here's the result:
http://img239.imagevenue.com/loc438/th_93528_fbsd_lq4_122_438lo.jpg (http://img239.imagevenue.com/img.php?image=93528_fbsd_lq4_122_438lo.jpg)
(windowed)

EDIT:
BTW this is on 6.4-STABLE as you can see from the screenshot. Ports are all updated. The GPU is an Nvidia 8500 GT.
Using CURRENT, cutting edge core (quoting the 1st post), doesn't mean that it has more probability to work; I think that at a certain time in the (hoping far) future they will stop working.
As soon as I can, I'll try on 7.1-STABLE and report back, ATM, I'm not planning to install CURRENT.

[arundel]

I've tried it again, as I thought that it can be working no more.
I've literally followed the pr, here's the result:
http://img239.imagevenue.com/loc438/th_93528_fbsd_lq4_122_438lo.jpg (http://img239.imagevenue.com/img.php?image=93528_fbsd_lq4_122_438lo.jpg)
(windowed)

EDIT:
BTW this is on 6.4-STABLE as you can see from the screenshot. Ports are all updated. The GPU is an Nvidia 8500 GT.
Using CURRENT, cutting edge core (quoting the 1st post), doesn't mean that it has more probability to work; I think that at a certain time in the (hoping far) future they will stop working.
As soon as I can, I'll try on 7.1-STABLE and report back, ATM, I'm not planning to install CURRENT.

i think the reason why you're able to run 3d apps under bsd is that the linuxulator in 6 is still based on the linux 2.4 kernel. whereas 7 and 8 try to emulate the linux 2.6 kernel.

could you post the output of `sysctl compat.linux` and `pkg_info -xI linux_base` please?

cheers.

[arundel]

alright everyone. it seems there's only one way to run linux 3d apps under freebsd: you need to switch back to linux kernel version 2.4 emulation. the linuxulator is not fully compatible with the linux kernel version 2.6 yet.

here are the steps necessary:

1. uninstall the linux_base-* port installed on your system
2. do `sysctl compat.linux.osrelease=2.4.2`
3. do `echo "compat.linux.osrelease=2.4.2" > /etc/sysctl.conf`
4. do `echo "OVERRIDE_LINUX_BASE_PORT=fc4" > /etc/make.conf`
5. install emulators/linux_base-fc4

rebooting or reloading the linux kernel module isn't necessary! now you should be able to run most linux 3d apps. i tested the quake 4 demo and the ut2004 demo so far.

if you update or reinstall the nvidia drivers be sure to execute the following script afterwards in order for id software games to find some necessary binaries:

#!/bin/sh
cd /compat/linux/usr/local/lib/
ln -is ../../lib/libGL.so.1
ln -is ../../lib/libGLcore.so.1
ln -is ../../lib/libnvidia-tls.so.1

cheers.

[zebdits]

i think the reason why you're able to run 3d apps under bsd is that the linuxulator in 6 is still based on the linux 2.4 kernel. whereas 7 and 8 try to emulate the linux 2.6 kernel.

could you post the output of `sysctl compat.linux` and `pkg_info -xI linux_base` please?

cheers.

I know for sure that at least rtcw and linux-enemyterritory are working with 7.1-STABLE, linux_base-f8 and compat.linux.osrelease: 2.6.16 because I have them on another pc.
As I've said, I'll do some other tests with q4 and d3 but ATM I have not enough space for the data files.

[zebdits]

Sorry but you are damn right.
I remembered that I installed a newer linux_base at the earlier 7.0 days, maybe fc6, then I switched back right because of the problems with linux-* games.
I'm still almost always using 6-STABLE as my main desktop as I am a little lazy and too busy and because of some issues I have with 7.1.
Anyway, maybe this can help moving forward: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/132510

[zebdits]

BTW, if it does matter, I've also noticed time ago that while installing/upgrading nvidia-driver using linux_base-fc[68], ldconfig dumps core with a message like kernel too old.

[IncubuS]

No luck with the x11/linux-f8-xorg-libs. :(

[arundel]

i don't think the problem is ports related. imo the problems are being caused by the linuxulator not being able to emulate the linux kernel 2.6 100%. if that's the case there's nothing we can do except wait until the linuxulator get's fixed.

here's a problem report: http://www.freebsd.org/cgi/query-pr.cgi?pr=133144

a thread on EMULATION: http://lists.freebsd.org/pipermail/freebsd-emulation/2009-April/005823.html

and one on CURRENT: http://lists.freebsd.org/pipermail/freebsd-current/2009-March/004563.html

so far nobody seems to be taking care of the problem however.

if anybody is able to run linux games using the linuxulator 2.6, please tell us how you managed to do so.

cheers.

[adamk75]

For what it's worth, I am able to run linux cames with the linuxulator using 2.6 with the open source radeon and intel drivers. ut2004 and gish work just fine. That's not to say there isn't a problem with the linuxulator, but if there is, nvidia seems to be the one affected by it.

Adam

[arundel]

playing linux games under linuxulator 2.6 is definitely possible. installing the graphics/linux_dri or linux_dri_devel e.g. let's you play linux games with every NVIDIA card. however the performance is very bad since the libGL which get's installed by that port isn't optimized for NVIDIA cards.

the problem with not being able to run linux 3d apps under freebsd with NVIDIA's driver mustn't be blamed on NVIDIA. all they do is to ship the freebsd driver with the very same linux libraries that are being installed by the linux drivers.

the linuxulator is supposed to emulate the linux kernel. since the linux drivers work under linux, but don't under freebsd it's obvious that the linuxulator is not doing it's job!

sadly the linuxulator 2.6 is being promoted as being perfect. obviously that's not true.

[zebdits]

sadly the linuxulator 2.6 is being promoted as being perfect. obviously that's not true.
From /usr/ports/UPDATING
20090401:
AFFECTS: users of linux Fedora 8 infrastructure ports
AUTHOR: bsam@FreeBSD.org

ATTENTION! Those ports are not default for any version of FreeBSD for now
and may be used with FreeBSD versions 7.2 and above (8-CURRENT is better)
using compat.linux.osrelease=2.6.16 and linux_base-f8. Please, note that
2.6.16 is not fully supported on 7.x (ex., some syscalls are missing
and cannot be MFCed due to a native FreeBSD ABI breakage).

[arundel]

i'm running CUURENT!

From /usr/ports/UPDATING
20090401:
AFFECTS: users of linux Fedora 8 infrastructure ports
AUTHOR: bsam@FreeBSD.org

ATTENTION! Those ports are not default for any version of FreeBSD for now
and may be used with FreeBSD versions 7.2 and above (8-CURRENT is better)
using compat.linux.osrelease=2.6.16 and linux_base-f8. Please, note that
2.6.16 is not fully supported on 7.x (ex., some syscalls are missing
and cannot be MFCed due to a native FreeBSD ABI breakage).

[zebdits]

Zander, can you shed some light on this problem?

It looks similar to this one:
http://www.nvnews.net/vbulletin/showthread.php?t=124233

There are also a recent PR about it:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/133144

Thanks.