nvidia-legacy304-kernel on -current
 

I figured I'd start a separate thread here at this point, if for no other reason, so as to avoid further clogging ponce's SBo-on-current thread! ;)

Here's what we know so far: with some minor hacking/patching nvidia-legacy304 compiles and runs on Slackware -current. (kernel 5.13.13)

Here's the catch: to use it, you must compile your own kernel. (The only way to avoid rolling-your-own kernel is if your kernel is below v5.8.) These days, post v5.8, nvidia needs the "lkdtm.ko" kernel module to survive.

According to kernel docs, this module is really only used for testing/intentional-crashing, etc. I imagine only kernel devs and such would ever utilize the module functions day-to-day. (LKDTM -> Linux Kernel Dump Test Module:)) We need one of those functions, however: the nvidia code relies on the native_write_cr4() syscall. Before v5.8 we could access this syscall without the lkdtm module. But since then, the native_write_cr4 functionality is exposed if and only if lkdtm is present. :(

All the stock Slackware kernel configs lack the required lkdtm module. Since it is such an obscure, little-used, and potentially abused kind of module, it only makes sense that Slackware--and other distros--disable it by default.

Personally, I'm gonna risk it. Now that I've actually gotten my QuadroFX 3500 humming on -current, I'll start "rolling my own." It works, so it avoids the landfill... for a while longer, anyway...

I don't know if anybody else out there is still running an nvidia that's too old for 340-108, but if so, I hope to have the revised SlackBuild script ready soon.

After that, I may even look into the native_write_cr4() situation and perhaps find an alternative syscall that nvidia's code could utilize. (That'll take a lot more reading--if I'm still up for more.;))

I am interested in the Nvidia 340-108 driver, waiting for that Slackbuild script.

On the other hand, shouldn't the post title change to "nvidia-legacy340-kernel on -current"?


Good luck with that job!

The post title shouldn't change because I'm not working with the 340 version. I'm working on 304. Thus, the title of this thread captures precisely what I actually meant to convey.

I thought I made it plenty clear in my post: I'm working with a card that is "too old" for 340--mine works only with 304, not 340.

Looking up nvidia-340-legacy at slackbuilds.org reveals that it already has a maintainer:If you are interested in keeping nvidia-340 running, I encourage you to contact him. Perhaps he (or ponce, or someone else) is working on a Slack 15.0 version as we speak--I don't know. (Nor would I presume to speak for Mats.)

Let me repeat, for the record, I have volunteered to take over the currently unmaintained code for legacy-304, only. I wouldn't propose to take over Mr. Tegner's 340 SlackBuild--if for no other reason, just because I don't own a single 340-compatible card to test it with.:)

I do run nvidia 304 drivers on arch linux but with some compromises:
1) xorg-server is at version 1.19.xx
2) linux-lts414
These are the latest version of xorg-server and linux that I know by trial and error that work with nvidia 304 drivers (both in AUR).
I've saved a package from the Arch Linux Archive for nvidia 304 drivers but do not have a PKGBUILD.
I would be interested in your solution for the 304 drivers on latest version of the linux kernel and the xorg-server as the linux-lts414 support will be dropped in January 2024.
So far I've only played with slackware in virtualbox, but I'm curious about it, I might try it on the metal one day.

Not arch or slackware, but I have a machine with nvidia 6200 that uses those drivers. For ubuntu bionic (kernel 4.15) they didnt package the driver and there was a patch that could make the official nvidia version install. For ubuntu focal (kernel 5.4) I've been stuck with noveau, if there's a way to make nvidia prop install that would be interesting. You mentioned recompiling kernel only needed above 5.8; so hmmm does that mean theres a way to install it on 5.4?

It's good to know that someone out there is in the same boat as me!

RE xorg-server: I've learned during this process that 1.19.x xorg-server is the absolute latest that will work with the nVidia 304 driver. The driver is utterly incompatible with xorg-server 1.20.x. Xorg-server 1.20 implements a new ABI that will never work with nVidia's drivers. See my post here for details on how I learned this the hard way! ;)

And while the kernel module builds just fine on modern kernels, the other part (i.e., the proprietary, closed-source binary that nVidia provides) was compiled for the older ABI (xorg-server =< 1.19.) Since the incompatibility is at a binary level, only the nVidia folks can possibly remedy the situation. Two ways they could make it work:
1. Recompile the closed-source part in-house, and release that new binary to the world.
2. Release the source code itself, then we could recompile it ourselves--patching the code as needed.

While nVidia could choose to do one of the above, I don't think they ever will. After all, it's not exactly in their interest to keep old cards running when they've got new ones to sell!

In summary, if you choose to keep rolling with nvidia304--and not nouveau--you will be restricted to xorg-server 1.19.7 and lower. (Note that the 1.19.7 version gets labelled "legacy," in spite of being released just two years ago.)

Sure, provided you adhere to the restriction mentioned above: xorg-server must be 1.19.7 or lower.

As far as kernel versions go, 5.4 should be good to go, as-is: no "roll-your-own" kernel needed.

Please see this github page for a series of patches that should bring the nvidia kernel module into line with linux kernels v4.12 to v5.6. (I haven't rightly tested this myself, having jumped from kernel v4.4 straight to v5.13, but I'd have to assume that these should work for your v5.4.)


Good luck! (And, please, feel free to post here the results--working or otherwise.:))

PS. A quick note about the patches: my forthcoming SlackBuild script incorporates all ten of these, plus 12 more! It seems that at every 5.x kernel release, something else goes wonky, viz a viz nVidia. It's these additional patches that allow the kernel module to continue to compile on the most modern kernels--i.e., above v5.6.

Thanks for reply.

I'm not expert on setting up linux, the kinda thing slackware users understand. My linux experience is with debian and ubuntu and using their packages, etc, and don't imagine using differnet xorg than distro provided. I think with slackware you have more control so I may be intruding in your subforum.

But, as far as I can tell, with ubuntu bionic, I'm using xorg 1.20.8; its the upgrade to ubuntu focal I dunno how to make nvidia-304 work on, but I wouldn't consider changing xorg, at that point I either must be linux guru (and not use ubuntu base), or just waste $20 buying a video card on craigslist.

[And this I did btw, my kid needed webgl 2.0 for school videoconference feature to set background image or something, so we bought nvidia 750 on craigslist for $40 and now she's good... but thats a different machine]

Butfor now ubuntu bionic base with patched driver on that machine is perfectly fine. But yknow, in 2023 or something, I may need a new solution, so keeping my eyes open....

Think nothing of it. It's true that I post pretty much only in the Slackware section, but that's only because all other distros are things of the past, for me anyway, since I first "got Slack." ;)

And while my work on the nVidia drivers has been tailored for Slackware, I just want to help anyone who still uses these old cards to keep on using them--regardless of distro. As I've stated in other threads here, my attitude is: "If the hardware still works, why throw it out?"

And, to be honest, my "slack-solution" should be relatively easy to translate to Arch, Debian, etc.

Ah-ha! I can tell you from personal experience that nothing will make you a "guru" quicker than adopting Slackware! Check out my introductory post here. Looking back on it, I feel like I frittered away over 15 years--buying into the myth that Slackware is for "experts only." As I state lower down in that thread, I learned more Unix/Linux fundamentals in just a few months on Slackware than I had in more than a decade with other distros.

So, I would encourage you (and everyone) to give it a try--it's not nearly as "scary" as people make it out to be. And these days, you can always test it out in a Virtual Machine, before making the decision to install it on your actual hardware.:)

For reference, this is where I found instructions and patch to install nvidia-304 on ubuntu 18.04 (kernel 4.15) [X 1.20.8]
https://adufray.com/blog/2018/06/02/...-127-on-bionic

Here are my 340.108 driver and kernel modules SlackBuild-scripts. The driver builds and works fine with Xorg 1.20.13 in -current (15.0RC1).
I am still running kernel 5.4.y because nVidia R340.108 doesn't support kernel 5.7.y or later without patching. R340 is sadly no longer maintained by nVidia, but you are free to try these kernel patches from Ponce's GitHub if that works for you:
https://github.com/Ponce/slackbuilds...gacy340-driver
https://github.com/Ponce/slackbuilds...gacy340-kernel
https://github.com/Ponce/slackbuilds...kernel/patches
https://github.com/warpme/minimyth2/...-340.108/files
Update 2021-09-16:
I've tried to compile the kernel modules (nvidia.ko and nvidia-uvm.ko) using the above patches on kernel 5.14.5 but it fails. I'm going to stay with kernel 5.4.147.
Regards,
Mats

Update
 

Stage 1 is complete!

For those of us who intend to continue running our nVidia cards with the proprietary driver instead of nouveau, one of the challenges we face is the incompatibility of the driver with the 1.20 version(s) of xorg-server that ships in Slackware -current.

So, I have been working this week on a new SlackBuild to compile and package the previous version(s) of xorg-server. I finished testing last night and would like to announce the release of the xorg-server-legacy-1.19.7 SlackBuild. (I plan to submit it to SBo as soon as submissions are re-opened.)

In all fairness, I should point out that "my" SlackBuild borrows very heavily from volkerdi's official x11.SlackBuild. (Some parts were lifted wholesale!) The official Slackware version is much more all-encompassing than what's required for our limited purposes. E.g., volkerdi's script can build all portions of x11 in one go: libs, fonts, etc. Since all we are interested in is the Xserver itself, I've trimmed it down and adapted it to this more limited scope. (I also had to work out a couple of small patches to account for GL being provided by libglvnd now.)

While I developed and compiled this in a Slack-current VM, I have installed the finished package on metal and verified that it does work with the nvidia-legacy304 drivers.

Since we can't post tar-balls as attachments here on the forum, I would be willing to email my SlackBuild to anyone who wants a sneak preview. Feedback welcomed. (Just post a message in this thread to request a copy.)

While this package is intended for use with legacy nVidia drivers, it should work just as well with any other proprietary drivers that have been deprecated by the vendor.

See the attached README for more information.

another update
 

Progress continues...

While I don't wish to jinx myself by declaring victory prematurely, it seems that I've gotten all my ducks in a row and have the nvidia-legacy-304 drivers fully working in -current.

This past week turned out to be a good time to test, since -current bumped the kernel version multiple times. This allowed me to run my SlackBuilds repeatedly, with fresh kernels seemingly every other day, and they came off without a hitch. Below is a summary of all three of the major components involved:

1. xorg-server-legacy: As mentioned in my last post, work on this part seems to be complete. SlackBuild script completes successfully, and the server itself functions as expected in -current.

2. nvidia-legacy304-driver: This one took several tweaks to make it work in -current. Mostly minor stuff--like "don't ship .la files"--but there was one that took me quite a while to figure out. Namely, I'd get the nvidia up and running but after each reboot, it would be broken. Symptoms included no window decorations, no desktop background, and it would take about a full minute for the mouse cursor to show up. When the mouse pointer finally did appear, it was the old (mid-1980s?) Xserver fallback of a big black "X" with left-click only. Eventually I tracked it down: apparently the nVidia driver was clobbering symlinks related to GL/GLX. This was throwing libglvnd into serious disarray. So, I added a few lines to the doinst.sh file to check for the presence of libglvnd, and if found, take action to keep the symlinks sane. With this addition, I now have a working nvidia desktop that persists across reboots.

3. nvidia-legacy304-kernel: As could be imagined, this one took the most work. For me, having been using this kernel module on Slack 14.2 w/ the 4.4.x kernel, leaping all the way up to kernel 5.13.x in -current was a challenge. As stated a few posts back, I found a series of patches on github that brought nvidia in line up to about kernel 5.6. I had to adapt and/or create about a dozen more to get this up to kernels 5.12+. (Including a brand new one that wasn't needed just a few weeks ago when I started this project--it applies only to kernels 5.14+.)

The real kick in the pants, however, came when I discovered that starting with kernel 5.8, the nvidia module needs access to a particular kernel module that is disabled in the stock Slackware kernels. (The "lkdtm" module--see above.) With many fits and starts, I was able to build functionality into my SlackBuild that will test for the presence of the needed module and to automatically build a compatible kernel, at the user's discretion. I've set it up so that the user can pass the "AUTO_KERN" variable on the command line, which will instruct the script to build a LKDTM-enabled kernel before proceeding to build the nvidia module. I also made the AUTO_KERN option flexible: available options include Y, generic, huge, both, all, or custom. When choosing "AUTO_KERN=y" the script will search for a kernel config file for you, using the path of least resistance.

What remains is to clean up the script, removing all the testing cruft, and to complete work on the documentation. README will need to be mostly rewritten from scratch, and additional documents describing the full range of AUTO_KERN options and their usage will also be necessary.

In summary, nvidia-304 works again! New Slackware--check. New kernels--check. New xorg--check. So, if you are one of the very few who still runs one of these ancient nVidia cards, the switch to Slackware 15 will no longer demand switching to nouveau, nor chucking your old card into the landfill.

How are things on slackware current regarding 304 nvidia drivers ?
On arch I've had to downgrade xf86-input-libinput from 1.2.0 to 1.1.0 because GUI did not respond to input, although the tty (cli) was responding just fine, both keyboard and mouse (GPM).
I see from the logs that xf86-input-libinput was upgrade from 1.1.0 to 1.2.0 on september 20th, did that affect anything on slackware current ?

No ill effects here. Just checked that my Slackware -current install is up to date and is indeed using xf86-input-libinput 1.2.0, and all is working as expected.