nvidia 340.108 (no-compat32) on linux kernel 5.15.19
 

I would just like to report that it is possible to run a patched version of the nvidia 340.108-no-compat32 driver on linux kernel 5.15.19 (for slackware64-15.0 RELEASE).

The patches are here:
https://aur.archlinux.org/packages/nvidia-340xx

Files:
0001-kernel-5.7.patch
0002-kernel-5.8.patch
0003-kernel-5.9.patch
0004-kernel-5.10.patch
0005-kernel-5.11.patch
0006-kernel-5.14.patch
0007-kernel-5.15.patch
0008-kernel-5.16.patch
20-nvidia.conf
https://us.download.nvidia.com/XFree...o-compat32.run

It seems to work only with the no-compat32 driver, so no multilib support. If it can work with the regular driver with compat32, maybe someone can tell me.

Only patch files 0001 to 0007 are needed for slackware64-15.0 / kernel 5.15.19. They have to be applied in order, 0001 until 0007. This requires extracting the nvidia .run file using the -x option. Then, cd into the extracted directory and run something like "patch -p1 < ../0001-kernel-5.7.patch" etc. for each patch file. Finally, you can reboot onto kernel 5.15.19 (assuming you have configured and installed it as a boot option) and run the nvidia-installer (or nvidia-installer -k 5.15.19, on a 4.4 kernel). Anyhow, it is working for me so far, on slackware64-14.2.

I still run slackware64-14.2, fully patched. But, I have installed kernel 5.15.19 on slackware64-14.2 so that I can test it with my hardware. I have custom-configured 5.15.19 based on the slackware64-15.0 kernel-generic config file, answering No to all hardware drivers I do not need and Yes or Module to those I do need (following my 4.4.302 config). My hard disks setup is gpt\md-raid1(boot)\ext4 and gpt\md-raid6\luks\lvm(root and swap)\ext4, but is working okay on 5.15.19. I assume that 15.0 initrd will work the same by default, as it does in 14.2, to setup my hard disks.

If this kernel 5.15.19 + patched nvidia 340.108 proves to be stable on slackware64-14.2, then I may proceed to upgrade to slackware64-15.0 packages. For now, I may just keep testing the kernel with my hardware, which is old: Intel Xeon 3450 (lynnfield core i7, 4/8 cores) on Asus P7F-E mainboard, LSI SAS1068E SAS/SATA HBA, GeForce 240GT video.

Slackware64-14.2 has been extremely stable and reliable for the whole 6+ years, and also longer going back to 13.0 on this same hardware. I am not sure that I really need to upgrade yet! But, it would be nice to get the new kde etc. So far, so good... so maybe I will upgrade later!

I tried doing this on Slackware 15.0 and confirm that these patches allow the driver to compile and install. Unfortunately there are problems with the display: the cursor blinks and often overwrites square blocks around it. Also video display appears to flicker. I have an Nvidia GeForce 210.

I'm trying to set up nouveau but so far have not succeeded (this machine was upgraded from Slackware 14.2 where I had it running the proprietary nvidia driver 340.108)

Sounds like the flickring is due to the fact you are still using the nouveau driver?
Thats the issue i got when trying to run nouveau drivers for my NVIDIA ION Graphics.

Are you sure you blacklisted the nouveau kernel driver?
If not, then create a file named "nvidia-installer-disable-nouveau.conf" and save it in "/etc/modprobe.d/".
for ex:
And add these lines:
After you saved the file, then reboot the system.

What i did was to compile kernel 4.4.302, an alternative is to switch to kernel 5.4.178 as the kernal 4.4.X is EOL (3rd February)

Thanks but nouveau was blocked (and had been in the last 5 years runnign 14.2 with the nvidia driver). As it turns out I now managed to install nouveau and it runs much better than the patched nvidia one.

I got this working using the patches with a rather ancient GeForce 8400 GS. No flickering, so far.

I'd tried using the nouveau driver, but I was getting occasional hard lockups which I couldn't even use the Alt-SysRq keys to get out of.

This is what I experienced with nouveau, as well. For me, the lockups always happened at the moment of entering or exiting full-screen mode for movies.

Once I determined that it wasn't the media player (the same thing would happen with VLC, MPlayer, etc,) I blacklisted nouveau, switched to nVidia, and no more lockups.

My guess is that the nouveau developers won't be spending much, if any, time trying to straighten out these issues for such old cards/GPUs. So, as long as we can keep patching the nVidia code to keep it working, why not? :)

In my case, I use an even older nVidia card that requires the 304 version of the driver. It is now up to 23 individual patches to keep it working up to kernel 5.17. Pinxi output is:

JayByrd: It would be nice if you could share those patches, I am trying to get my FX2500M working on a 5.10 kernel.

I have an ongoing thread addressing nvidia-legacy304 on Slackware -current(15.0).

The latest versions of the necessary SlackBuild scripts, including patches, are in posts #26 & #28 of that thread.

thanks for the pointer.

I have recommended before (it is that time again) to do this: Make the text file /etc/modprobe.d/nvidia.conf with the lines:

I don't know if this will fix your flickering and problems, but try it.

I have managed to compile the 304.137 on Linux DevStation_464f34925507 5.10.89TS #1 SMP PREEMPT Sat Jan 1 16:14:12 UTC 2022 x86_64 Common KVM processor AuthenticAMD GNU/Linux

Thinstation 6.2.13, so far so good now it remains to be seen how to downgrade x-server to 1.19. Hopefully I will have my Dell M90 with a FX2500M 4G mem playing fortnite on windows with accellerated graphics as a thin client anytime real soon ;), one thing failed in the build when linking. ERROR: file .nv-kernel.o.cmd not found

I simply just touched the file in $NVIDIA/kernel/

Remains to be seen if it worked when I can test the kernel module on physical hardware.

Many thanks for your effort JayByrd!


The patches I applied, were
[root@TS_chroot]/ts/ports/opt/nvidia_304_137# ls *.patch
0002-pud-offset-4.12.patch 0015-ioctl32-5.9.patch
0003-nvidia-drm-pci-init-4.14.patch 0016-get-user-pages-5.9.patch
0004-timer-4.15.patch 0017-conftest-headers.patch
0005-usercopy-4.16.patch 0018-vmalloc-5.8.patch
0006-do_gettimeofday-5.0.patch 0019-flush-tlb-5.8.patch
0007-subdirs-5.3.patch 0020-license-5.9.patch
0008-on-each-cpu-5.3.patch 0021-get-user-pages-4.4.168.patch
0010-proc-ops-5.6.patch 0022-kmap_types-5.11.patch
0011-compile-tests-5.6.patch 0023-task_struct_state-5.14.patch
0012-compile-tests-5.7.patch 0024-stdarg-5.16.patch
0013-nv-mlock-5.8.patch 0025-pde-data-5.17.patch


and this one (specific for Thinstation)
--- Makefile.kbuild 2022-02-21 21:41:07.049849296 +0000
+++ Makefile.kbuild.orig 2022-02-21 21:43:01.152849296 +0000
@@ -216,7 +216,7 @@
endif

KBUILD_PARAMS += KBUILD_VERBOSE=$(NV_VERBOSE)
-KBUILD_PARAMS += -C $(KERNEL_SOURCES) SUBDIRS=$(PWD)
+KBUILD_PARAMS += -C $(KERNEL_SOURCES) M=$(PWD)
KBUILD_PARAMS += ARCH=$(ARCH)

#
@@ -226,10 +226,10 @@
.PHONY: suser-sanity-check rmmod-sanity-check build-sanity-checks

suser-sanity-check:
- @if ! $(CONFTEST) suser_sanity_check; then exit 1; fi
+ #@if ! $(CONFTEST) suser_sanity_check; then exit 1; fi

rmmod-sanity-check:
- @if ! $(CONFTEST) rmmod_sanity_check; then exit 1; fi
+ #@if ! $(CONFTEST) rmmod_sanity_check; then exit 1; fi

build-sanity-checks:
@if ! $(CONFTEST) cc_version_check full_output; then exit 1; fi
@@ -257,9 +257,9 @@
#

module-install: suser-sanity-check module
- @mkdir -p $(MODULE_ROOT)/video; \
- install -m 0664 -o root -g root $(MODULE_OBJECT) $(MODULE_ROOT)/video; \
- PATH="$(PATH):/bin:/sbin" depmod -ae;
+ #@mkdir -p $(MODULE_ROOT)/video; \
+ #install -m 0664 -o root -g root $(MODULE_OBJECT) $(MODULE_ROOT)/video; \
+
#
# This target builds, then installs, then creates device nodes and inserts
@@ -267,8 +267,8 @@
#
package-install: module-install rmmod-sanity-check
- @PATH="$(PATH):/bin:/sbin" modprobe $(MODULE_NAME) && \
- echo "$(MODULE_OBJECT) installed successfully.";
+ #@PATH="$(PATH):/bin:/sbin" modprobe $(MODULE_NAME) && \
+ #echo "$(MODULE_OBJECT) installed successfully.";
#
# Build an object file suitable for further processing by the installer

For the record, that touch command is in the SlackBuild script. Since you built it manually, that didn't get executed.:)

So now, I've removed it from the build script and added the touch line to the patches so it should be handled automatically when building manually.

By the way, I think any further discussion on this one should happen over in the 304 thread. After all, twy started this thread for nvidia 340--no need to clutter this one any further with off-topic conversation.;)

Btw... compat32 is working for me with the patched 340.108 on 5.15.26 (slackware64-14.2 still). I ran 32-bit wine and an old windows program displayed without any problem. I downloaded the regular 340.108 driver and patched it. I guess I can upgrade to 15.0 soon since this kernel and video driver are working well. I could make an LVM snapshot of my 14.2 disk before I upgrade. If the upgrade breaks too much, then I can merge the snapshot back. I am also waiting on slackbuilds.org to support 15.0, but that might not stop me from upgrading eventually. I am cautious about this upgrade 14.2->15.0, but I think a lot of others have already upgraded!

SBo package nvidia-legacy340-kernel
 

So while nouveau did work, it lacks performance for 1920x1080@60Hz video and I am back to installing the nvidia 340.108 driver. This time I tried using the SBo packages that have been updated to 15.0. The driver package builds well, however the kernel package (nvidia-legacy340-kernel) fails to build the kernel module:
right at the beginning of the slackbuild, after the patches are applied, there is an error and a warning that could be related:

On this machine I am still on kernel 5.15.19, but could easily upgrade to 5.15.27.
Has anyone else been able to build this kernel module with the SBo package?

I recognize that failure, as I experienced the same thing when building the older 304 version of the nvidia kernel module...

Here is the patch I used:You may have to adjust the line numbers, etc. to make this work for the 340 version, but the idea is the same. This patch was originally developed for the 470 version of the nvidia kernel module by joanbm on github.


As to that 2nd code block you posted, you can safely ignore all that noise. Those messages about "kernel configuration invalid" and "the compiler differs from the one used to build the kernel" have been showing up for years, but have never stopped the module from building for me. (My guess is that those are purely informational and that the nVidia build system spits them out because it is expecting a 2.6 kernel!:D)