nvidia-drivers-340.108

[Brumi-2021]

Hi Shibotto and Ionen, and Randy Andy ,

Recently I opened a thread about general Opengl problems , with an old recycled laptop, with GPU : NVIDIA Geforce 9300M GS .
https://forums.gentoo.org/viewtopic-p-8735719.html#8735719

But after checking re recently , sudo dsmesg output , I think it is directly related to all this previous threat . (apologize for it)

I could read that in that link , I can find my needed NVIDIA driver (nvidia-drivers-340.108-r4.ebuild) ,
https://github.com/achurch/noglvnd


I already masked the , >=x11-drivers/nvidia-drivers-390.154 (to block the supported current gentoo NVIDIA drivers)

[TXT] nvidia-drivers-390.1..> 12-Jun-2022 19:10 14K
[TXT] nvidia-drivers-390.1..> 02-Aug-2022 20:40 14K
[TXT] nvidia-drivers-470.1..> 12-Jun-2022 19:10 15K
[TXT] nvidia-drivers-470.1..> 02-Aug-2022 20:40 15K
[TXT] nvidia-drivers-510.7..> 12-Jun-2022 19:10 15K
[TXT] nvidia-drivers-510.8..> 02-Aug-2022 20:40 15K
[TXT] nvidia-drivers-515.4..> 21-Jul-2022 08:10 17K
[TXT] nvidia-drivers-515.5..> 28-Jun-2022 19:40 17K
[TXT] nvidia-drivers-515.6..> 02-Aug-2022 20:40 17K


But I am not sure , the commands that I need to do
for installing the old nvidia-drivers-340.108-r4 ,
and to integrate it correctly to the my kernel version , inux-5.18.13-pentoo

I could also read on above posts, that shiboto created and excellent new nvidia legacy 340 repo
https://gitlab.com/shibotto/nvidia-legacy
I read the instructions , and seems clear , but I think it would not work with my kernel linux 5.18. 13 .

Congratulations for your great job and strong support to the community!

Any help or guide will be highly appreciated,
Cheers,

[rogge]

Here your'll find patches for newer Kernels:

https://aur.archlinux.org/packages/nvidia-340xx

[rogge]

Hello again,

I tried to compile the uptodate nvidia-kmod for Kernel 5.15.94, but it failed, again and again and I really don't know why.

[Mistwolf]

Known issue, see here: https://gitlab.com/shibotto/nvidia-legacy/-/issues/2

[rogge]

[nuku97]

Hallo everyone,

I use the driver x11-drivers/nvidia-drivers-340.108-r101:0/340::nvidia-legacy on my old notebook with Nvidia Quattro NVS 160M graphics card, because the OpelnGL performance of open source Nouveau for this card is really bad in games.

I didn't really use my notebook during the last 1,5 years but kept updating it regulary, to have it ready for use whenever needed. Now I had to use it again but unfortunately noticed a problem related to the graphics driver, but don't know exactly when or with which package update this problem was introduced:

When using the nvidia-driver above, most QT/KDE application crash with a segmentation fault, dmesg reporting something like this:

[Hu]

As I read that thread, the solution is that you need to use libglvnd, rather than directly loading libGL.so from nvidia-drivers. Is your notebook unable to use any newer nVidia drivers than the 340 series? Remaining on such an old series is likely to cause you more problems as time passes.

[logrusx]

[nuku97]

Hi all,

thanks for your responses.

Yes, this driver is unfortunately the last driver for my notebook's Nvidia Quatro NVS 160M card. After all, the notebook (Dell E6400) is from 2009... and yes, I already expected this trouble with the closed source driver. Still, the notebook is good enough for my use cases (used only a few weeks per year when visiting parents or parents in law), while my daily driver is now a powerful desktop with - of course - an AMD Radeon card and open source drivers

But back to the topic, in case somebody is interested:

I spend a few more hours and changed the overlay from nvidia-legacy to noglvnd (https://github.com/achurch/noglvnd), which was also mentioned somewhere above in this thread, getting rid of libglvnd and restoring the old "eselect opengl" behaviour. Of course I used emerge and revdep-rebuild to rebuild all packages with changed USE flags and library deps. But still: the QT/KDE apps crash just like before.

So this seems not (just) to be a problem with libglvnd, but maybe a problem with QT. In some other forum posts on the internet, somebody writes that this problem with the nvidia-driver occurs since Qt 5.15.4. Looking at the changelogs of the portage tree and comparing them to the last time I was really using the notebook about 1,5 years ago, indeed the QT version was lower than this at that time. I tried to downgrade QT but quickly gave up due to dependencies of latest stable KDE packages. And I don't think it makes sense to invest much more time and downgrade also all the KDE packages etc. Also, I tried to compile all kde-*/* and dev-qt/* with USE=-opengl, to no success.

So, my conclusion:
- for now, I will either use Nouveau with KDE for productivity or Nvidia-drivers with ICEWM for "gaming". Might try another lightweight DE without QT like LxDE to replace KDE....
- will continue to watch this thread, maybe someone comes up with a solution after all, who knows...
- in case I will buy a new notebook, I will try to grab one with a Radeon....

Have a nice day!
Florian

[Hu]

If you want to pursue this further, understanding the exact nature of the crash might be helpful to know which component(s) are at fault. We would want to see the full backtrace, with symbols. Register context may or may not help.

[Geneslaf]

[JanR]

[Geneslaf]

[molletts]

[nuku97]

Thank you for sharing the patchelf command! This also worked for me and my KDE desktop runs fine again on this old notebook from 2009!
[/code]

[Shibotto]

Long time no see folks, let me cut straight to the important stuff:

• I've been using and testing the AUR patches for a couple of weeks and everything seems OK with 5.10, 5.15, 6.1 and 6.6. I'm dropping the kernel config checks though, because I've never actually checked them (I'm a -bin user) and they are most likely wrong/obsolete. If anyone can make a comprehensive list spanning at least the 4 kernel versions mentioned above, I will gladly include it.
  
  
• Thank you so much for the patchelf solution, I will do that directly in the ebuild.
  

ETA this week, barring unforeseen circumstances.


↓↓↓ Chatting time (aka you don't have to read this) ↓↓↓

So, it's been 2 years. Did my old Nvidia hardware die? Was I too busy to take care of this overlay? None of the above, I just... didn't strictly need to. After all my goal from the very beginning was to set it up in a way that it would very hardly ever conflict with whatever might happen in Gentoo, so I sat comfortably on 5.15 and kept upgrading the rest of the distro without a worry in the world. And that's the end of the happy, "mission accomplished" part of this story.

At the same time, I've been very disheartened by the maintenance struggle kernel developers are facing with LTS versions. LTS' are vital for us, because any kernel at any given time could be the end of the line, the last one which this relic of a driver could be reasonably adapted to. So when I look at the right column of the longterm table and see a pile of "Dec, 2026"... why should I even bother with newer kernels?

What changed then? For starters, linux-mod.eclass got deprecated. It will probably still be there for quite some time, but I don't like sitting on a time bomb (well, not another one) waiting for portage to fail on me. We have a new eclass of course and it even has a quick migration guide to make the transition super simple. As always, many, many thanks to Ionen for the hard work. The other reason is that since Gentoo only supports < 3 years old kernels (except for vanilla-sources), as a gentoo-kernel-bin user I only have 1 year left of 5.15. I'm already missing when "Dec, 2026" sounded bad. So now was a good time to get this moving again.

Oh, and the Qt issue. I can't make any excuses here: I've been aware of the problem since around mid 2022, but because I didn't know of a proper solution I've never brought it up. I've spent a lot of time on that though. First I tried debugging, but what I got didn't ring any bell at the moment. So I did the only next obvious thing: install another Gentoo and upgrade it until the problem shows up again. Ionen, if you remember seeing me hunting for a 4 months old or so stage3 on IRC around last December, now you know what I was doing . It took a long time, but if I remember correctly the trigger on my system was libpcre2 which stopped linking directly to libpthread, the only component which was bringing libpthread in the chain of dependencies of every Qt programs. After that the LD_PRELOAD workaround was obvious, but that's as far as my knowledge of libraries goes. I didn't know about patchelf and I still really don't; the sad thing is that if I mentioned this here I would have been able to fix this months ago. My bad.

[dmpogo]

Well, that 3 year limit on LTS kernels from gentoo is a bummer. When you build a server, it's lifetime is usually more that 3 years, and during its life you do not what to play with kernel upgrades much. It is funny if may older nvidia-340 computer will get the newest kernel among all my machines as the result (they all stuck at 4.19)

[nuku97]

Hallo everyone,

I have been using the ebuilds from the nvidia-legacy overlay without problems for the past 1,5 years.

After some system updates however, the OpenGL part of the nvidia driver doesn't work for me anymore. I don't know which update caused the problem. Also re-emerging nvidia-drivers and nvidia-kmod didn't solve the problem.

I can start a X11 session with IceWM without problems. But OpenGL programs like glxgears, steam, even "konsole" from KDE don't start anymore.

glxgears reports:

[Ionen]

The reason 340.xx was dropped from the tree earlier than it would have otherwise is because it does *not* support libglvnd, and that means __GLX_VENDOR_LIBRARY_NAME=nvidia cannot be used. 390.xx also only has partial support, but that still makes the situation better. Newer (still supported) branches instead do not support not using libglvnd, making it required.

340 legacy ebuild does three notable things, adjust LDPATH so applications do *not* use libglvnd even if installed, then adjust the Xorg module path (like 390 needs) to override the vendor neutral glx module, then tells Xorg to ignore ABI version incompatibility given the module is too old for modern Xorg and just been lucky that it still worked anyway.

aka from the ebuild:

[nuku97]

Ionen, thanks for the explanation regarding libglvnd.

For now I will live with the PRELOAD workaround or switch to nouveau. Maybe someone else will stumble upon the same problem, find a solution and post it here. The files you mentioned (xorg, env.d) are installed and X11 is using the nvidia driver, something just doesn't work with the GL applications anymore - after lots of updates since I really used the affected system. I probably won't be able to identify which update exactly broke the system.

So you are right, it would be wise to move on to newer hardware, this is a notebook from 2009. Because only rarely need, so I didn't feel like spending money for something new. But I might look for a cheap refurbished replacement

Thanks and have a nice day!

[dmpogo]

I realized that I have not tried opengl programs on my nvidia-340 machine after upgrade. Did not logged into KDze yet, playing with FVWM instead. Which would be enough for me if push comes to shovel. Need to go and see !

Indeed it does not work without LD_PRELOAD

[Geneslaf]

[dmpogo]

it is not just mesa-progs, kde parts such as konsole also do not work, do they also use libOpenGL ?

[Ionen]

Ah, hadn't noticed that patch for mesa-progs. In a glvnd world it's technically preferable to use libOpenGL, but that doesn't work out for the usage here. As I mentioned a libOpenGL -> libGL symlink may be worth trying, afaik libOpenGL is libGL just with a few things in less (not more, so afaik it "shouldn't" be missing anything).

[dmpogo]