304.135 driver fails to insert on Fedora 26 (4.12.5 kernel) with "Unknown symbol init_mm"
This is using the latest package from the RPM Fusion folks: [code] $ sudo akmods --kernel 4.12.5-300.fc26.x86_64 Checking kmods exist for 4.12.5-300.fc26.x86_64 [ OK ] Building and installing nvidia-304xx-kmod $ rpm -ql kmod-nvidia-304xx-4.12.5-300.fc26.x86_64-304.135-5.fc26.x86_64 /usr/lib/modules/4.12.5-300.fc26.x86_64/extra /usr/lib/modules/4.12.5-300.fc26.x86_64/extra/nvidia-304xx /usr/lib/modules/4.12.5-300.fc26.x86_64/extra/nvidia-304xx/nvidia.ko $ sudo modprobe nvidia modprobe: ERROR: could not insert 'nvidia': Unknown symbol in module, or unknown parameter (see dmesg) $ dmesg|tail -1 [ 3362.664779] nvidia: Unknown symbol init_mm (err 0) [/code] Looks like the RPM Fusion package already includes patches that are supposed to fix the driver on 4.12, but clearly something is missing. Any suggestions? For reference, there's a bug open already for this at RPM Fusion, [url]https://bugzilla.rpmfusion.org/show_bug.cgi?id=4629[/url]
This is using the latest package from the RPM Fusion folks:

$ sudo akmods --kernel 4.12.5-300.fc26.x86_64
Checking kmods exist for 4.12.5-300.fc26.x86_64 [ OK ]
Building and installing nvidia-304xx-kmod
$ rpm -ql kmod-nvidia-304xx-4.12.5-300.fc26.x86_64-304.135-5.fc26.x86_64
/usr/lib/modules/4.12.5-300.fc26.x86_64/extra
/usr/lib/modules/4.12.5-300.fc26.x86_64/extra/nvidia-304xx
/usr/lib/modules/4.12.5-300.fc26.x86_64/extra/nvidia-304xx/nvidia.ko
$ sudo modprobe nvidia
modprobe: ERROR: could not insert 'nvidia': Unknown symbol in module, or unknown parameter (see dmesg)
$ dmesg|tail -1
[ 3362.664779] nvidia: Unknown symbol init_mm (err 0)


Looks like the RPM Fusion package already includes patches that are supposed to fix the driver on 4.12, but clearly something is missing. Any suggestions?

For reference, there's a bug open already for this at RPM Fusion, https://bugzilla.rpmfusion.org/show_bug.cgi?id=4629

#1
Posted 08/18/2017 08:52 PM   
Driver version too old. 384.59 inserts fine (Optimus/Bumblebee issues aside).
Driver version too old. 384.59 inserts fine (Optimus/Bumblebee issues aside).

#2
Posted 08/21/2017 06:39 AM   
Well sure, the 340xx series works fine too with that kernel. But obviously I can't use either due to the age of the graphics card in that machine - that's why the 304xx series still exists.
Well sure, the 340xx series works fine too with that kernel. But obviously I can't use either due to the age of the graphics card in that machine - that's why the 304xx series still exists.

#3
Posted 08/21/2017 04:46 PM   
If you hardware is that old, why don't you use the nouveau driver instead? In my experience it works beautifully (even on my Pascal GPU, despite the inability to change GPU/RAM clocks and P states).
If you hardware is that old, why don't you use the nouveau driver instead? In my experience it works beautifully (even on my Pascal GPU, despite the inability to change GPU/RAM clocks and P states).

Artem S. Tashkinov
Linux and Open Source advocate

#4
Posted 08/21/2017 07:25 PM   
[quote="arcivanov"]Driver version too old. 384.59 inserts fine (Optimus/Bumblebee issues aside).[/quote] Just FYI, there are 3 main trees of nvidia drivers, current, 340.XX (legacy) for stuff older than Fermi or so, and then 304.XX (legacy^2) for really old stuff. I don't think he is using ancient drivers by choice (and I don't believe that these drivers support newer cards). That said, both legacy driver trees get less love than current stable/beta. Edit: actually, there is even more trees than that, but the 304/340 are the ones still maintained. [list] [.]Latest Long Lived Branch version: 384.59[/.] [.]Latest Short Lived Branch version: 381.22[/.] [.]Latest Legacy GPU version (340.xx series): 340.102[/.] [.]Latest Legacy GPU version (304.xx series): 304.135[/.] [.]Latest Legacy GPU Version (71.86.xx series): 71.86.15[/.] [.]Latest Legacy GPU Version (96.43.xx series): 96.43.23[/.] [.]Latest Legacy GPU Version (173.14.xx series): 173.14.39[/.] [/list] Support list: http://www.nvidia.com/object/IO_32667.html
arcivanov said:Driver version too old. 384.59 inserts fine (Optimus/Bumblebee issues aside).


Just FYI, there are 3 main trees of nvidia drivers, current, 340.XX (legacy) for stuff older than Fermi or so, and then 304.XX (legacy^2) for really old stuff. I don't think he is using ancient drivers by choice (and I don't believe that these drivers support newer cards).

That said, both legacy driver trees get less love than current stable/beta.

Edit: actually, there is even more trees than that, but the 304/340 are the ones still maintained.
  • Latest Long Lived Branch version: 384.59
  • Latest Short Lived Branch version: 381.22
  • Latest Legacy GPU version (340.xx series): 340.102
  • Latest Legacy GPU version (304.xx series): 304.135
  • Latest Legacy GPU Version (71.86.xx series): 71.86.15
  • Latest Legacy GPU Version (96.43.xx series): 96.43.23
  • Latest Legacy GPU Version (173.14.xx series): 173.14.39


Support list: http://www.nvidia.com/object/IO_32667.html

#5
Posted 08/21/2017 07:32 PM   
tpruzina is correct; we can't use the nouveau drivers and so some of our older machines use the 340xx series and others the 304xx series. Something broke in the 4.12 kernel with the 304xx drivers, but our machines using the 340xx series or the latest release still work OK. FWIW, the 304xx drivers work just fine with the 4.11 kernel, so those machines will stay on 4.11 until we can resolve this.
tpruzina is correct; we can't use the nouveau drivers and so some of our older machines use the 340xx series and others the 304xx series. Something broke in the 4.12 kernel with the 304xx drivers, but our machines using the 340xx series or the latest release still work OK. FWIW, the 304xx drivers work just fine with the 4.11 kernel, so those machines will stay on 4.11 until we can resolve this.

#6
Posted 08/21/2017 11:27 PM   
Again if you have the old hardware, why don't you use LTS distros/kernels? Or better yet CentOS 7.4 which you'll have zero troubles with.
Again if you have the old hardware, why don't you use LTS distros/kernels? Or better yet CentOS 7.4 which you'll have zero troubles with.

Artem S. Tashkinov
Linux and Open Source advocate

#7
Posted 08/22/2017 10:16 AM   
Hi. I managed to track down the problem. In [b]nv-linux.h[/b] there is a call to [b]pgd_offset_k[/b] function, which uses [b]init_mm[/b] (not exported for a while). I don't know much about kernel development, so for the test I just replaced that call with a constant. The system booted fine (X working), but there are some error messaged in dmesg related to the constant I used (therefore it's obviously not a proper fix). [b]upd:[/b] This code is not used in 340.* driver (and it's not used for a while -- [b]init_mm[/b] symbol is not's exported since 2.6.26). So, I backported this code (see attached patch) and it seems to work. Also, the error in dmesg is unrelated to my changes. It's just a coincidence (well, beef-related constants are kinda popular).
Hi. I managed to track down the problem. In nv-linux.h there is a call to pgd_offset_k function, which uses init_mm (not exported for a while). I don't know much about kernel development, so for the test I just replaced that call with a constant. The system booted fine (X working), but there are some error messaged in dmesg related to the constant I used (therefore it's obviously not a proper fix).

upd: This code is not used in 340.* driver (and it's not used for a while -- init_mm symbol is not's exported since 2.6.26). So, I backported this code (see attached patch) and it seems to work.

Also, the error in dmesg is unrelated to my changes. It's just a coincidence (well, beef-related constants are kinda popular).

#8
Posted 08/26/2017 07:13 PM   
Nogo for me, but I'm using Slackware64. Thanks for trying.
Nogo for me, but I'm using Slackware64. Thanks for trying.

#9
Posted 09/02/2017 02:39 AM   
That's strange. Works for me on Debian Testing, and I have seen positive feedback from Fedora (see bugtracker link in the first post) and Ubuntu (there is a thread on launchpad) users. Are you using SlackBuild from slackbuilds.org? In that case you should add the appropriate patch command (like `patch -Np1 -i /path/to/patch`) before `make SYSSRC=$KERNELPATH module || exit 1` in the nvidia-legacy304-kernel SlackBuild file. Also, what's the output of `nm /lib/modules/$KERNEL/kernel/drivers/video | grep init_mm`? (substitute $KERNEL with the output of `uname -r`)? [b]upd:[/b] If your module doesn't compile at all, then you should apply other patch for 4.12 first. You can grab it here: [url]https://bugzilla.rpmfusion.org/show_bug.cgi?id=4629#c11[/url] (it also includes my changes).
That's strange. Works for me on Debian Testing, and I have seen positive feedback from Fedora (see bugtracker link in the first post) and Ubuntu (there is a thread on launchpad) users. Are you using SlackBuild from slackbuilds.org? In that case you should add the appropriate patch command (like `patch -Np1 -i /path/to/patch`) before `make SYSSRC=$KERNELPATH module || exit 1` in the nvidia-legacy304-kernel SlackBuild file.

Also, what's the output of `nm /lib/modules/$KERNEL/kernel/drivers/video | grep init_mm`? (substitute $KERNEL with the output of `uname -r`)?

upd: If your module doesn't compile at all, then you should apply other patch for 4.12 first. You can grab it here: https://bugzilla.rpmfusion.org/show_bug.cgi?id=4629#c11 (it also includes my changes).

#10
Posted 09/02/2017 10:21 AM   
Scroll To Top

Add Reply