# Cannot play any Linux games anymore for about a year now



## cabriofahrer (Apr 20, 2018)

FreeBSD amd 64 11.1-p9, nvidia-driver-390.48, linux_base-c6-6.9_6, Geforce 750 GTX, all packages up to date.

I have always played all Linux games on that machine, but since some update of packages in the past, absolutely NO Linux game works anymore on that machine, I don't know if that is due to a newer version of nvidia-driver or the linuxulator. I always get a message like this with all games, no matter if linux-doom3, linux-quake4-demo, etqw or whatever:


```
----- R_InitOpenGL -----
Setup X display connection
dlopen(libGL.so.1)
Initializing OpenGL display
Using XFree86-VidModeExtension Version 2.2
DGA DirectVideo Mouse (Version 2.0) initialized
Free86-VidModeExtension Activated at 640x480
Using 8/8/8 Color bits, 8 Alpha bits, 24 depth, 8 stencil display.
Fatal X Error:
  Major opcode of failed request: 153
  Minor opcode of failed request: 3
  Serial number of failed request: 42
BadValue (integer parameter out of range for operation)
Fatal X Error:
  Major opcode of failed request: 153
  Minor opcode of failed request: 5
  Serial number of failed request: 45
BadMatch (invalid parameter attributes)
GL_RENDERER: (null)
GL_EXTENSIONS: (null)
```

My kldstat shows this:


```
$ kldstat
Id Refs Address            Size     Name
 1   66 0xffffffff80200000 1f6e480  kernel
 2    1 0xffffffff82170000 22fa0    firewire.ko
 3    3 0xffffffff82193000 abe08    linux.ko
 4    4 0xffffffff8223f000 dfa0     linux_common.ko
 5    1 0xffffffff8224d000 170b28   nvidia-modeset.ko
 6    2 0xffffffff823be000 13481c8  nvidia.ko
 7    1 0xffffffff83707000 147f8    tmpfs.ko
 8    1 0xffffffff8371c000 e690     cuse.ko
 9    1 0xffffffff8372b000 1a8d8    fuse.ko
10    3 0xffffffff83746000 89ca8    vboxdrv.ko
11    1 0xffffffff83a19000 5936     fdescfs.ko
12    1 0xffffffff83a1f000 a8c4     linprocfs.ko
13    1 0xffffffff83a2a000 2ed4b    vboxguest.ko
14    1 0xffffffff83a59000 2986     uhid.ko
15    1 0xffffffff83a5c000 10913    snd_uaudio.ko
16    1 0xffffffff83a6d000 245c     ulpt.ko
17    1 0xffffffff83a70000 3650     ums.ko
18    2 0xffffffff83a74000 2cbf     vboxnetflt.ko
19    2 0xffffffff83a77000 c57d     netgraph.ko
20    1 0xffffffff83a84000 43da     ng_ether.ko
21    1 0xffffffff83a89000 4016     vboxnetadp.ko
22    1 0xffffffff83a8e000 3c947    linux64.ko
23    1 0xffffffff83acb000 1518e    ext2fs.ko
24    1 0xffffffff83ae1000 51fa     geom_linux_lvm.ko
$
```

But here is one interesting thing: On two other PC's, one with an old nvidia card (6600 I think) that uses nvidia-driver-304, FreeBSD amd64 10.4 and another with FreeBSD amd64 11.1 and some integrated ATI HD3000 chip, Linux games DO work. If on those I install e.g. linux-doom3-demo, linux_base-c6-6.9 just gets installed the same as dependency like on my main PC and the game starts. And as all FreeBSD's are amd64, it is the same linux_base package on the tree PC's.
I did observe though that on the other two PC's a klstat only shows "linux.ko" but no "linux64.ko".

I thought then that doing a kldunload of "linux64.ko" would do the trick, but that does not work either, so what is wrong here with my main PC?

Does it have something to do with the nvidia-driver for newer cards and kmod (because, as I said the old card with nvidia-driver-304 works and ATI as well) or with the 6.9-version of the linuxulator in conjunction with nvidia-driver? I really don't know what to do.


----------



## shkhln (Apr 22, 2018)

You should downgrade nvidia-driver to 384.111.


----------



## cabriofahrer (Apr 23, 2018)

Thanks for your reply, shkhln. I just downloaded nvidia-driver 384.111 from the nvidia-site and installed that, but it doesn't work either. In the past I had already tried with 384.59 (even older version) and it did not work either. So I don't know if the version would have to be even older or what, but this cannot be the proper solution anyway. Is it possible that it has to do something with this?

https://reviews.freebsd.org/D5141

And that therefore some ports should be installed with certain options?

Another question: Installing the old nvidia-driver with "make install" does not create a package. So how do you cleanly uninstall?


----------



## shkhln (Apr 23, 2018)

cabriofahrer said:


> I just downloaded nvidia-driver 384.111 from the nvidia-site and installed that





cabriofahrer said:


> Installing the old nvidia-driver with "make install" does not create a package.



See https://forums.freebsd.org/threads/fetch-older-version-of-a-certain-port.39602.



cabriofahrer said:


> So how do you cleanly uninstall?



Hm... I think (but haven't verified) in that particular case installing nvidia-driver from ports would overwrite all these files. Don't bother.


----------



## cabriofahrer (Apr 23, 2018)

shkhln said:


> Hm... I think (but haven't verified) in that particular case installing nvidia-driver from ports would overwrite all these files. Don't bother.



Yes, I can confirm that now, was no problem. But what do you think about the information in the link I mentioned? Did you actually run into the same problem as I and do Linux games (32 bit) work for you right now with nvidia-driver?


----------



## shkhln (Apr 23, 2018)

I don't actually run games under Linux emulation (wine is vastly easier in practice), but OpenGL did work for me until 390.x.


----------



## PaddyMac (May 5, 2018)

I don't know if your problem is the same as what I have experienced, but one issue I have had with trying to play Linux games under FreeBSD is that the libdrm version currently in CentOS (I'm using the CentOS 7 packages) is an out-of-date version with a known bug where it isn't able to load the gl driver properly. I've been waiting patiently for an upgrade, but CentOS is slow to upgrade packages. I suppose the primary audience for Linux compatibility is people running server software, but it seems to me that a more up-to-date set of Linux packages such as from Fedora would be a nice option for people like us who want to run games. Now that I think about it, your issue is probably different if you're using the nVidia driver because the issue I'm having would only come up when using the open source drivers such as for Intel or AMD.


----------



## shkhln (May 5, 2018)

I'm pretty sure Nvidia broke OpenGL under Linuxulator. In general, their driver reliability seems to be on the decline since the introduction of nvidia-modeset kernel module, so it's not entirely unexpected. It would be nice to see reports from other users, though.


----------



## shkhln (May 18, 2018)

shkhln said:


> wine is vastly easier in practice



I've just realized Nvidia "forgot" to put a 32-bit libGL.so into NVIDIA-FreeBSD-x86_64-396.24.tar.gz (they do so for Linux). And they deprecated the x86 distribution altogether... Now, _that_ is an actual PITA.


----------



## cabriofahrer (Jun 21, 2018)

shkhln said:


> I've just realized Nvidia "forgot" to put a 32-bit libGL.so into NVIDIA-FreeBSD-x86_64-396.24.tar.gz (they do so for Linux). And they deprecated the x86 distribution altogether... Now, _that_ is an actual PITA.



So that's it? They just "forgot to put a 32-bit libGL.so into..., and they do so for Linux". Can't this be reported?!?!?


----------



## shkhln (Jun 22, 2018)

No, that's not your current problem. 396.x branch is not yet in the ports.


----------



## cabriofahrer (Jun 22, 2018)

So what is my current problem then? And what can I do?


----------



## shkhln (Jun 22, 2018)

The only solution I know is downgrading nvidia-driver to 384.111 with _portdowngrade_ utility. That should be enough to make 32-bit Linux OpenGL apps work. If that doesn't help you then please post (as attachment) full truss output for linux-doom3/linux-quake4-demo/etqw/whatever.


----------



## hrenznaet (Jun 23, 2018)

shkhln said:


> You should downgrade nvidia-driver to 384.111.


Why?
I have gtx970, nvidia-driver 390.59. Should I downgrade too?


----------



## shkhln (Jun 23, 2018)

hrenznaet said:


> Why?



Why not?


----------



## hrenznaet (Jun 23, 2018)

shkhln said:


> Why not?


Because presumably newer version have more features and less bugs, as it usually happens with software in general.
There are some exclusions (say, firefox degraded since v57, so no power users use firefox more recent than v56), so if that is the case - I'd like to know.


----------



## shkhln (Jun 23, 2018)

In this case the new feature is broken Linux(ulator) support.


----------



## hrenznaet (Jun 23, 2018)

Thanks, that's what I wanted to know.
In my experience linuxulator was always broken in FreeBSD.
Could you provide some prooflink to the ticket in issue tracker?


----------



## shkhln (Jun 23, 2018)

You don't read carefully, I'm interested in some validation myself. The most relevant PR is probably https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228287, but it's not sufficiently detailed to say for sure (what's the point of testing against 340.106?). Also, I don't expect FreeBSD devs to fix issues within the Nvidia's blob, so it's a bit pointless anyway.


----------



## cabriofahrer (Jun 26, 2018)

shkhln said:


> The only solution I know is downgrading nvidia-driver to 384.111 with _portdowngrade_ utility. That should be enough to make 32-bit Linux OpenGL apps work. If that doesn't help you then please post (as attachment) full truss output for linux-doom3/linux-quake4-demo/etqw/whatever.



Portdowngrade did not show 384.111 in the list, but I found 384.90. But unfortunately when running it with the according revision I got this:


```
# portdowngrade x11/nvidia-driver r451134
svn: E200029: Couldn't perform atomic initialization
svn: E200030: SQLite compiled for 3.24.0, but running with 3.23.1
Something went wrong with svn...  Ensure you have the correct revision!
```

I cannot attach an output of `truss linux-doom3-demo`. If I do `truss linux-doom3-demo > linux-doom3-demo.txt` I get an empty Textfile.


----------



## shkhln (Jun 26, 2018)

cabriofahrer said:


> ```
> svn: E200030: SQLite compiled for 3.24.0, but running with 3.23.1
> ```




`pkg upgrade` is in order I suppose?




cabriofahrer said:


> `truss linux-doom3-demo > linux-doom3-demo.txt` I get an empty Textfile.




Csh syntax for redirecting stdout+stderr is `truss linux-doom3-demo >& linux-doom3-demo.txt`, something similar works for bash (can't remember).


----------



## cabriofahrer (Jun 26, 2018)

OK, did an upgrade of base and userland and managed to install nvidia-driver-384.90 which is below 384.11, right? But still no luck. This time I am attaching the output. But I would like to ask you something: When you state that one should downgrade to 384.111 to solve the problem, are you actually able to run 32-bit linux-games? Does e.g. linux-doom3-demo work on your machine?


----------



## shkhln (Jun 26, 2018)

> linux_clone(0x3d0f00,0x2c943494,0x2c943bd8,0xffffb4b0,0x2c943bd8) = 100399 (0x1882f)
> truss: could not find thread



Can you run `truss -f linux-doom3-demo >& linux-doom3-demo.txt`?



cabriofahrer said:


> Does e.g. linux-doom3-demo work on your machine?



Never tried it. I'm using 392.24 now, so it wouldn't work.


----------



## cabriofahrer (Jun 27, 2018)

Here you go:


----------



## shkhln (Jun 27, 2018)

> truss: could not find thread


No dice. Let's try with ktrace then: `ktrace linux-doom3-demo`, `kdump | grep nvidia -B 10 -A 10`, `kdump | grep ioctl`.


----------



## cabriofahrer (Jun 27, 2018)

OK, here you go:


----------



## shkhln (Jun 27, 2018)

You likely have /compat/linux/usr/lib/libGL.so.1 symlinked to /compat/linux/usr/lib/libGL.so.384.111. It should point to whatever version you have installed right now (384.90?).


```
1331 doom.x86 CALL  linux_stat64(0xffffa5f0,0xffffa41c)
  1331 doom.x86 NAMI  "/compat/linux/dev/nvidiactl"
  1331 doom.x86 NAMI  "/compat/linux"
  1331 doom.x86 NAMI  "/compat/linux/dev/nvidiactl"
  1331 doom.x86 STRU  struct stat {dev=117, ino=9309873, mode=020666, nlink=1, uid=0, gid=0, rdev=50175, atime=1507885399.961294000, mtime=1507885399.961294000, ctime=1507885399.961337000, birthtime=1507885399.961276000, size=0, blksize=32768, blocks=0, flags=0x0 }
```

Do you have anything at path /compat/linux/dev/nvidiactl? If so, remove it.


----------



## cabriofahrer (Jun 27, 2018)

shkhln said:


> Do you have anything at path /compat/linux/dev/nvidiactl? If so, remove it.



It looks like it is not even a directory. But anyway, I am giving you the complete output and listing of the paths that you are asking for:


```
$ cd /compat/linux/dev/
$ ls
null        nvidiactl    shm
$ cd nvidiactl
cd: nvidiactl: Not a directory
$ ls -l
total 4
-rw-r--r--  1 root  wheel       0 Feb  4  2017 null
crw-rw-rw-  1 root  wheel  0xc3ff Oct 13  2017 nvidiactl
drwxr-xr-x  2 root  wheel     512 Jun 12 18:32 shm
$ pkg info | grep nvidia-driver
nvidia-driver-384.90           NVidia graphics card binary drivers for hardware OpenGL rendering
$ pwd
/compat/linux/dev
$ cd ..
$ cd usr/lib
$ pwd
/compat/linux/usr/lib
$ ls
db4.3.29
dri
games
gconv
gio
i686
krb5
ld-2.12.so
ld-linux.so.2
ld-lsb.so.3
libacl.so.1
libacl.so.1.1.0
libanl-2.12.so
libanl.so.1
libattr.so.1
libattr.so.1.1.0
libblkid.so.1
libblkid.so.1.1.0
libBrokenLocale-2.12.so
libBrokenLocale.so.1
libbz2.so.1
libbz2.so.1.0.4
libc-2.12.so
libc.so.6
libcap.so.2
libcap.so.2.16
libcidn-2.12.so
libcidn.so.1
libcom_err.so.2
libcom_err.so.2.1
libcrypt-2.12.so
libcrypt.so.1
libcuda.so.1
libcuda.so.384.111
libcuda.so.384.59
libcuda.so.384.90
libdb_cxx-4.3.so
libdb-4.3.so
libdb-4.7.so
libdl-2.12.so
libdl.so.2
libdrm_amdgpu.so.1
libdrm_amdgpu.so.1.0.0
libdrm_intel.so.1
libdrm_intel.so.1.0.0
libdrm_nouveau.so.1
libdrm_nouveau.so.1.0.0
libdrm_nouveau2.so.2
libdrm_nouveau2.so.2.0.0
libdrm_radeon.so.1
libdrm_radeon.so.1.0.1
libdrm.so.2
libdrm.so.2.4.0
libe2p.so.2
libe2p.so.2.3
libEGL_nvidia.so.0
libEGL_nvidia.so.384.111
libEGL_nvidia.so.384.59
libEGL_nvidia.so.384.90
libEGL.so
libEGL.so.1
libelf-0.164.so
libelf.so.1
libexpat.so.1
libexpat.so.1.5.2
libext2fs.so.2
libext2fs.so.2.4
libfam.so.0
libfam.so.0.0.0
libfontconfig.so.1
libfontconfig.so.1.4.4
libfontenc.so.1
libfontenc.so.1.0.0
libform.so.5
libform.so.5.7
libformw.so.5
libformw.so.5.7
libfreebl3.chk
libfreebl3.so
libfreeblpriv3.chk
libfreeblpriv3.so
libfreetype.so.6
libfreetype.so.6.3.22
libgamin-1.so.0
libgamin-1.so.0.1.10
libgcc_s-4.4.7-20120601.so.1
libgcc_s.so.1
libgdbm.so.2
libgdbm.so.2.0.0
libgio-2.0.so.0
libgio-2.0.so.0.2800.8
libGL.so.1
libGL.so.1.2.0
libGL.so.384.111
libGL.so.384.90
libglapi.so
libglapi.so.0
libglapi.so.0.0.0
libGLdispatch.so
libGLdispatch.so.0
libGLESv1_CM_nvidia.so.1
libGLESv1_CM_nvidia.so.384.111
libGLESv1_CM_nvidia.so.384.59
libGLESv1_CM_nvidia.so.384.90
libGLESv1_CM.so
libGLESv1_CM.so.1
libGLESv2_nvidia.so.2
libGLESv2_nvidia.so.384.111
libGLESv2_nvidia.so.384.59
libGLESv2_nvidia.so.384.90
libGLESv2.so
libGLESv2.so.2
libglib-2.0.so.0
libglib-2.0.so.0.2800.8
libGLU.so.1
libGLU.so.1.3.1
libglut.so.3
libglut.so.3.9.0
libgmodule-2.0.so.0
libgmodule-2.0.so.0.2800.8
libgmp.so.3
libgmp.so.3.5.0
libgmpxx.so.4
libgmpxx.so.4.1.0
libgobject-2.0.so.0
libgobject-2.0.so.0.2800.8
libgssapi_krb5.so.2
libgssapi_krb5.so.2.2
libgssrpc.so.4
libgssrpc.so.4.1
libgthread-2.0.so.0
libgthread-2.0.so.0.2800.8
libhistory.so.6
libhistory.so.6.0
libICE.so.6
libICE.so.6.3.0
libidn.so.11
libidn.so.11.6.1
libjpeg.so.62
libjpeg.so.62.0.0
libk5crypto.so.3
libk5crypto.so.3.1
libkdb5.so.6
libkdb5.so.6.0
libkeyutils.so.1
libkeyutils.so.1.3
libkrb5.so.3
libkrb5.so.3.3
libkrb5support.so.0
libkrb5support.so.0.1
libLLVM-3.6-mesa.so
libm-2.12.so
libm.so.6
libmemusage.so
libmenu.so.5
libmenu.so.5.7
libmenuw.so.5
libmenuw.so.5.7
libmount.so.1
libmount.so.1.1.0
libmp.so.3
libmp.so.3.1.14
libncurses.so.5
libncurses.so.5.7
libncursesw.so.5
libncursesw.so.5.7
libnsl-2.12.so
libnsl.so.1
libnss_compat-2.12.so
libnss_compat.so.2
libnss_dns-2.12.so
libnss_dns.so.2
libnss_files-2.12.so
libnss_files.so.2
libnss_hesiod-2.12.so
libnss_hesiod.so.2
libnss_nis-2.12.so
libnss_nis.so.2
libnss_nisplus-2.12.so
libnss_nisplus.so.2
libnvidia-eglcore.so.384.111
libnvidia-eglcore.so.384.90
libnvidia-glcore.so.384.111
libnvidia-glcore.so.384.90
libnvidia-glsi.so.384.111
libnvidia-glsi.so.384.90
libnvidia-tls.so.384.111
libnvidia-tls.so.384.90
libOpenGL.so
libOpenGL.so.0
libpanel.so.5
libpanel.so.5.7
libpanelw.so.5
libpanelw.so.5.7
libpciaccess.so.0
libpciaccess.so.0.11.1
libpcprofile.so
libpcre.so.0
libpcre.so.0.0.1
libpcrecpp.so.0
libpcrecpp.so.0.0.0
libpcreposix.so.0
libpcreposix.so.0.0.0
libpopt.so.0
libpopt.so.0.0.0
libpthread-2.12.so
libpthread.so.0
libreadline.so.6
libreadline.so.6.0
libresolv-2.12.so
libresolv.so.2
librt-2.12.so
librt.so.1
libSDL-1.2.so.0
libSDL-1.2.so.0.11.3
libSegFault.so
libselinux.so.1
libsepol.so.1
libslang.so.2
libslang.so.2.2.1
libSM.so.6
libSM.so.6.0.1
libstdc++.so.5
libstdc++.so.5.0.7
libstdc++.so.6
libstdc++.so.6.0.13
libthread_db-1.0.so
libthread_db.so.1
libtic.so.5
libtic.so.5.7
libtinfo.so.5
libtinfo.so.5.7
libutil-2.12.so
libutil.so.1
libuuid.so.1
libuuid.so.1.3.0
libvdpau_nvidia.so
libverto-k5ev.so
libverto-k5ev.so.0
libverto-k5ev.so.0.0
libverto.so
libverto.so.0
libverto.so.0.0
libX11-xcb.so.1
libX11-xcb.so.1.0.0
libX11.so.6
libX11.so.6.3.0
libXau.so.6
libXau.so.6.0.0
libXaw.so.7
libXaw7.so.7
libXaw7.so.7.0.0
libxcb-composite.so.0
libxcb-composite.so.0.0.0
libxcb-damage.so.0
libxcb-damage.so.0.0.0
libxcb-dpms.so.0
libxcb-dpms.so.0.0.0
libxcb-dri2.so.0
libxcb-dri2.so.0.0.0
libxcb-dri3.so.0
libxcb-dri3.so.0.0.0
libxcb-glx.so.0
libxcb-glx.so.0.0.0
libxcb-present.so.0
libxcb-present.so.0.0.0
libxcb-randr.so.0
libxcb-randr.so.0.1.0
libxcb-record.so.0
libxcb-record.so.0.0.0
libxcb-render.so.0
libxcb-render.so.0.0.0
libxcb-res.so.0
libxcb-res.so.0.0.0
libxcb-screensaver.so.0
libxcb-screensaver.so.0.0.0
libxcb-shape.so.0
libxcb-shape.so.0.0.0
libxcb-shm.so.0
libxcb-shm.so.0.0.0
libxcb-sync.so.1
libxcb-sync.so.1.0.0
libxcb-xevie.so.0
libxcb-xevie.so.0.0.0
libxcb-xf86dri.so.0
libxcb-xf86dri.so.0.0.0
libxcb-xfixes.so.0
libxcb-xfixes.so.0.0.0
libxcb-xinerama.so.0
libxcb-xinerama.so.0.0.0
libxcb-xinput.so.0
libxcb-xinput.so.0.1.0
libxcb-xkb.so.1
libxcb-xkb.so.1.0.0
libxcb-xselinux.so.0
libxcb-xselinux.so.0.0.0
libxcb-xtest.so.0
libxcb-xtest.so.0.0.0
libxcb-xv.so.0
libxcb-xv.so.0.0.0
libxcb-xvmc.so.0
libxcb-xvmc.so.0.0.0
libxcb.so.1
libxcb.so.1.1.0
libXcomposite.so.1
libXcomposite.so.1.0.0
libXcursor.so.1
libXcursor.so.1.0.2
libXdamage.so.1
libXdamage.so.1.1.0
libXdmcp.so.6
libXdmcp.so.6.0.0
libXevie.so.1
libXevie.so.1.0.0
libXext.so.6
libXext.so.6.4.0
libXfixes.so.3
libXfixes.so.3.1.0
libXfont.so.1
libXfont.so.1.4.1
libXft.so.2
libXft.so.2.3.2
libXi.so.6
libXi.so.6.1.0
libXinerama.so.1
libXinerama.so.1.0.0
libxkbfile.so.1
libxkbfile.so.1.0.2
libXmu.so.6
libXmu.so.6.2.0
libXmuu.so.1
libXmuu.so.1.0.0
libXp.so.6
libXp.so.6.2.0
libXpm.so.4
libXpm.so.4.11.0
libXrandr.so.2
libXrandr.so.2.2.0
libXrender.so.1
libXrender.so.1.3.0
libXRes.so.1
libXRes.so.1.0.0
libXss.so.1
libXss.so.1.0.0
libXt.so.6
libXt.so.6.0.0
libXtst.so.6
libXtst.so.6.1.0
libXv.so.1
libXv.so.1.0.0
libXvMC.so.1
libXvMC.so.1.0.0
libXvMCW.so.1
libXvMCW.so.1.0.0
libXxf86dga.so.1
libXxf86dga.so.1.0.0
libXxf86misc.so.1
libXxf86misc.so.1.1.0
libXxf86vm.so.1
libXxf86vm.so.1.0.0
libz.so.1
libz.so.1.2.3
locale
lsb
modules
pm-utils
rtkaio
security
sse2
terminfo
tls
udev
vdpau
XXX-libGL.so.1.2.0.%%.orig-20180216
XXX-libGL.so.1.2.0.%%.orig-20180423
XXX-libGL.so.384.59.%%.orig-20180423
XXX-libnvidia-eglcore.so.384.59.%%.orig-20180423
XXX-libnvidia-glcore.so.384.59.%%.orig-20180423
XXX-libnvidia-glsi.so.384.59.%%.orig-20180423
XXX-libnvidia-tls.so.384.59.%%.orig-20180423
$ pwd
/compat/linux/usr/lib
$
```


----------



## shkhln (Jun 27, 2018)

I'm not asking you to list anything. I'm saying you should correct the symlink and remove the bogus device file*. E.g.

```
sudo rm /compat/linux/usr/lib/libGL.so.1
sudo ln -s /compat/linux/usr/lib/libGL.so.384.90 /compat/linux/usr/lib/libGL.so.1
sudo rm /compat/linux/dev/nvidiactl
```

* Apparently recent versions of Nvidia's libGL create /compat/linux/dev/nvidiactl if you happen to run any (Linux) application using libGL as root. Then libGL starts sendings ioctls to /compat/linux/dev/nvidiactl instead of /dev/nvidiactl which is not quite right.


----------



## cabriofahrer (Jun 27, 2018)

Thank you so much!!!! Executing the 3 commands above solved the problem! My question is now, how could this happen? Did anything go wrong with some upgrade in the past or did I accidentally run a Linux application as root in the past which I don't remember? So does this mean this was never a problem of the version of the nvidia-driver in the end? Can I upgrade or am I stuck to 384.90 now?


----------



## shkhln (Jun 27, 2018)

cabriofahrer said:


> am I stuck to 384.90 now?



Ask Nvidia maybe? I'm not sure if they even have an appropriate support channel. They seem to ignore FreeBSD questions on the Unix Graphics forum (https://devtalk.nvidia.com/default/board/97/freebsd/).


----------



## cabriofahrer (Jun 28, 2018)

OK, here is what I have just found out right now: After installing linux-c6-libpng because darkmod required it, I was back to where we started. Nothing worked. Uninstalling linux-c6-libpng did not change anything. But when I tried again


```
# rm /compat/linux/usr/lib/libGL.so.1
# ln -s /compat/linux/usr/lib/libGL.so.384.90 /compat/linux/usr/lib/libGL.so.1
```

Doom3 would work again. So it occurred to me that linux-c6-png was the culprit. And yes, after installing that package again, it did not work, but after running the two commands above once again everything was functional again. And once linux-c6-libpng installed, even darkmod would start!

So can you please interpret this? How can linux-c6-libpng do such a thing and mess with your libGL.so.1?

It looks like this is not Nvidia's fault then?


----------



## shkhln (Jun 28, 2018)

cabriofahrer said:


> How can linux-c6-libpng do such a thing and mess with your libGL.so.1?



Hm... I actually noticed before that there is some script/program relinking libGL.so.1 to the most recent libGL version in the same directory, but I don't know (and don't care) what exactly it is. You should remove libGL.384.111 since it obviously wasn't installed with pkg.



cabriofahrer said:


> It looks like this is not Nvidia's fault then?



I'm using very selective quoting for a reason, not for the fun of it. Read the previous response again.


----------



## Deleted member 54719 (Jun 28, 2018)

For what it's worth, maybe go outside of the freeBSD ports structure and go right to the nvidia geforce website.  that's ALWAYS where I get my drivers, and I know they have freeBSD drivers...probably an old enough legacy driver to test the problem more thoroughly.

And on a quick inspection of the OP, it kinds of smells like the more recent OGL canvas is not presenting an X visual that the game stuff can use.  This is actually a pretty common problem with neophyte OGL programmers.  They make the assumption that EVERYBODY supports the particular visual they want to use.


----------



## shkhln (Jun 28, 2018)

tempest766 said:


> For what it's worth, maybe go outside of the freeBSD ports structure and go right to the nvidia geforce website.



It's not worth it, specifically for reproducibility reasons: a port represents a known set of patches and settings. There exist a few patches in the nvidia-driver port (https://svnweb.freebsd.org/ports/head/x11/nvidia-driver/files/) and we don't want people to rediscover and reapply these fixes one by one.

Besides, you are not even a BSD user, so your positive experience with downloading and running vanilla driver is irrelevant.



tempest766 said:


> And on a quick inspection of the OP, it kinds of smells like the more recent OGL canvas is not presenting an X visual that the game stuff can use.  This is actually a pretty common problem with neophyte OGL programmers.  They make the assumption that EVERYBODY supports the particular visual they want to use.



OP's issue is actually solved.


----------



## Deleted member 54719 (Jun 28, 2018)

shkhln said:


> It's not worth it, specifically for reproducibility reasons: a port represents a known set of patches and settings. There exist a few patches in the nvidia-driver port (https://svnweb.freebsd.org/ports/head/x11/nvidia-driver/files/) and we don't want people to rediscover and reapply these fixes one by one.
> 
> Besides, you are not even a BSD user, so your positive experience with downloading and running vanilla driver is irrelevant.
> 
> ...



Ah yes, one boy's opinion...For ten plus years I've seen the "ported" nvidia drivers have problems on every platform they are hacked into.  Never had a lick of problems using the "direct from nvidia" driver, as long as they are installed (AFTER) the X11 packages. and who are you to make a judgement about what I use or don't use?  You know zero about me or what I do.


----------



## shkhln (Jun 28, 2018)

tempest766 said:


> and who are you to make a judgement about what I use or don't use?  You know zero about me or what I do.



Said it yourself in the other thread. Now scram.


----------



## cabriofahrer (Jun 28, 2018)

Hello tempest766,

you are not helping me here, so please do not use my thread to confront someone who is. I never had any problems using the nvidia-driver from the packages. And once trying to install it directly from Nvidia it did not solve this specific problem either. So I would like to politely ask you to stay down.



shkhln said:


> Hm... I actually noticed before that there is some script/program relinking libGL.so.1 to the most recent libGL version in the same directory, but I don't know (and don't care) what exactly it is. You should remove libGL.384.111 since it obviously wasn't installed with pkg.



Thanks for that advice. But what about doing a complete cleanup? That's why just in case I listed the whole content of the directory, because it looks like it contains a lot of repeated/obsolete stuff.

So what do you think if I uninstalled nvidia-driver and all linux-related packages (including linux_base-c6) and then did a `rm -rf /compat` and then reinstalled everything again?


----------



## shkhln (Jun 28, 2018)

cabriofahrer said:


> So what do you think if I uninstalled nvidia-driver and all linux-related packages (including linux_base-c6) and then did a `rm -rf /compat` and then reinstalled everything again?



That should work. Personally, I wouldn't bother, it's only couple of files.


----------



## cabriofahrer (Jun 28, 2018)

Well, thank you so much again for your help! I am not going to do that right now, but when I do, I will check if like that the new version of nvidia-driver works and report back. But until then (also after upgrading to FreeBSD 11.2) I guess I will just enjoy playing some linux-games with the awesome performance of FreeBSD...^^


----------

