Can't load nvidia-drm.ko on FreeBSD 14.3-RELEASE : unsupported file type.

ZioMario

ZioMario

Hello.

I've upgraded FreeBSD 14.2-RELEASE to 14.3-RELEASE and also performed a fresh installation of FreeBSD 14.3-RELEASE and I tried to install the nvidia-driver and the nvidia-drm-61-kmod,as you can see below :

1) nvidia-drm-61-kmod :

1_.jpg


2) nvidia-driver :

2_.jpg


3) and I've added the following parameters to rc.conf :

3_.jpg


4) as well as these parameters on loader.conf :

4_.jpg


5) and then I tried to load the nvidia-drm module several times,in different reinstallations,but everytime I get the error below :

5_.jpg


No idea about how to fix it.
 
Similar things have often happened to me. In every case, I was able to fix it by doing a gitup of my ports tree, then using ports to install nvidia-drm. The packages seem to get out of sync sometimes and doing a port build (from a fresh ports tree) seems to fix it for me. The nvidia-drm will usually rebuild the nvidia driver too.
 
The error in general means "wrong version in the kmod"

nvidia-drm and nvidia-driver come from ports.
On the upgraded system, did you do pkg upgrade -f?
The fresh install is a little odd.

Are your running your own package server/environment?
Have you tried rebuilding the port on your system?
 
--> Similar things have often happened to me.

This seems to be a problem that happens often. Shouldn't it be fixed once for all ?

--> Are your running your own package server/environment ?

What do u mean ? I'm using the packages offered by FreeBSD.

--> Have you tried rebuilding the port on your system?

I've installed the nvidia-driver and the nvidia-drm-61-kmod from the packages. Probably I should reinstall nvidia-drm-61-kmod from the ports ?
 
Yes, please reinstall the nvidia-kmod from ports, it should pull in the other stuff needed and there's a good chance that will fix the issue.
 
I feel your pain... no really, I felt this pain for a long long long time.

I have no idea what is going on with pkg at this point, but as you relate - YES pkg and freebsd-update are not returning the right nvidia-drm driver for NVidia cards. I upgraded my box from the 14.2-RELEASE to the 14.3-RELEASE many, many times and although (everything else was good) the Nvidia drivers were always for the 14.2-RELEASE no matter what I did with pkg. And YES - that's the linux_kfree_async error. Clearly that missing dynamic link symbol is the Linux kernel's version of the free(3) function call. No one has yet explained why that dynamic link symbol is even in the *BSD source code... but that's another story.

ZFS is your friend :).

Strangely the FreeBSD-Kmods fix (DOES WORK) with Intel graphic cards (at least in my case) on a different host - but nothing worked for a machine with an NVidia RTX 4070.

The good news is that (at last !) I got it working. But my steps to achieve this result are a bit painful.

STANDARD DISCLAIMER: FOLLOW THESE STEPS AT YOUR OWN RISK. I WOULD NEVER EVER RECOMMEND THAT YOU LISTEN TO ME ABOUT ANYTHING, OR ANYTHING THAT I WRITE.

a) Newly Install FreeBSD from CD/DVD/etc 14-3.RELEASE to your machine
b) Make sure you install "/usr/src" during the install which will have the latest ports source code for the 14.3-RELEASE - I installed (everything) on that install selection page (aka 32 bit libraries, kernel debug libraries, etc).
c) After the OS is installed -- (DO NOT) use pkg to install anything! But if some command or whatever is obviously missing from the O/S that you need in order to get "make" to run (see steps d/e) you can add it using "pkg". But largely you want the makefiles to do the all the package compiling and installing.
d) cd /usr/ports/graphics/nvidia-drm-61-kmod
e) make BATCH=yes
f) ** YOU MIGHT HAVE TO ADD A SYMBOLIC LINK TO PERL 5.40.2 WHICH I FOUND MISSING ** I guess the FreeBSD distro has upgraded the default perl to 5.40.3 -- but the Makefiles are still using an older version of perl. I (doubt) there is much difference between perl version 5.40.3 and 5.40.2 - but YMMV (it worked for me).

You can add the symbolic link as follows:
Shell> cd /usr/local/bin
Shell> ln -s perl perl5.40.2

g) Then run the make (again = step e) and it took around 2.5 hours to completely download a lot of stuff from the Internet, compile, install (on it's own) and complete the make. once that's done:

Shell> make install

and then try to load the nvidia-drm.ko file with:

Shell> kldload nvidia-drm

You can check to see if it successfully loaded with:

Shell> kldstat

If you get the linux_kfree_async error message again... it's okay to cry.

Good luck !
 
Don't use pkg to upgrade nvidia things on 14.3 until...
  • 14.2 is EoL'ed and pkg builder switches to 14.2,
  • or wait for the patch at PR 288314 to be accepted by admins of kmod repo admins, land to ports tree and applied to kmod pkg builder.
I get no reaction from the admins, so I cannot get it to be proceeded.
Committing PR 288314 is meaningless at all unless the concept itself works fine for kmod pkg builders and applied to the builders.
Also, applying the patch locally is meaningless for now, as it just divides x11/nvidia-driver* ports into kmod part and all others.
 
Maybe it should be added to the nvidia-driver pkg-message? I don't think it's there. Just one or two lines, like, If adding the nvidia-drm-kmod, please update your ports tree, then build nvidia-drm-kmod from ports.
 
scottro said:
Maybe it should be added to the nvidia-driver pkg-message? I don't think it's there. Just one or two lines, like, If adding the nvidia-drm-kmod, please update your ports tree, then build nvidia-drm-kmod from ports.
Click to expand...
No plan for now.
As this was always mandatory for all (at least that depends on LinuxKPI, which is always "moving goal") kmod ports until FreeBSD-kmods is provided.

And also, as I've already commented on #8 here, if the concept of my patch at PR 288314 works fine on "official kmod pkg builder (which I don't have access to it)", lands in ports tree and official kmod builder start using it, this problem should be fixed. And if the concept itself is OK, I believe my patch would already ready to land (at least, ready to be reviewed on Phablicator).
 
And more, many (hope not most) admins (including personal users who administrates their own single computer only) DOES NOT READ PKG-MESSAGE.

Maybe pkg should have mechanism to cache ALL pkg-message (including rendered files/pkg-message.in) for all installed/upgraded pkgs and show them with configured PAGER at the very end of the process, not to be missed within a plenty of other outputs.
 
Good point :). Or maybe make it viewable with pkg info -D so it's there--but it's the same problem, many people just skip it.
 
T-Aoki said:
Maybe pkg should have mechanism to cache ALL pkg-message (including rendered files/pkg-message.in) for all installed/upgraded pkgs and show them with configured PAGER at the very end of the process, not to be missed within a plenty of other outputs.
Click to expand...
pkg info -D -a shows all pkg-messages from everything you have installed. I sometimes use it when I think I missed something flashing by after installing a bunch of stuff.
 
SirDice said:
pkg info -D -a shows all pkg-messages from everything you have installed. I sometimes use it when I think I missed something flashing by after installing a bunch of stuff.
Click to expand...
Yes. But the problem is that it is NOT done in many cases, regarding posts here.

For example, pkg-message of x11/nvidia-driver* doesn't suggest loading nvidia GPU drivers via /boot/loader.conf but via kld_list variable in /etc/rc.conf for quite a long time, but too many problems as of loading them via /boot/loader.conf are still seen.

This would clearly mean pkg-message shown are often unread. Quite unfortunate as a de-facto maintainer.
 
scottro said:
Good point :). Or maybe make it viewable with pkg info -D so it's there--but it's the same problem, many people just skip it.
Click to expand...
Exactly.
Maybe pkg info -D -a as SirDice noted shows ALL pkg-message OF ALL INSTALLED PKGS, admins would be tired reading all every time.
I hope (just slight, unfortunately) displaying pkg-message of touched (installed or upgraded) ports at the end of the run, or adding an option to limit the output of pkg info -D -a for "done in last run", helps.
 
It's confusing because I have been using NVidia cards with FreeBSD for decades.

Honestly I "always" use NVidia cards when I build a FreeBSD machine because NVidia has always supported FreeBSD, so I have always supported NVidia with my money $$$. (aka "Always Support for your friends"). For years PCs were putting "It works in Windows Only" graphic cards into new PCs that were complete "junk" when it came to trying to use them for open source. NVidia supported FreeBSD and other O/S's during this time.

So if FreeBSD is going to support NVidia doesn't it make sense that point release upgrades from 14.2-RELEASE to 14.3-RELEASE should be "complete no brainers"? Why do we need to have a PHD in FreeBSD mechanics in order to install an NVidia driver on a "release point upgrade" on FreeBSD?

I have the time to spend literally "weeks" figuring this out... but my guess is that other FreeBSD users are not going to bother to do that (now or in the future).
 
CShell said:
It's confusing because I have been using NVidia cards with FreeBSD for decades.

Honestly I "always" use NVidia cards when I build a FreeBSD machine because NVidia has always supported FreeBSD, so I have always supported NVidia with my money $$$. (aka "Always Support for your friends"). For years PCs were putting "It works in Windows Only" graphic cards into new PCs that were complete "junk" when it came to trying to use them for open source. NVidia supported FreeBSD and other O/S's during this time.

So if FreeBSD is going to support NVidia doesn't it make sense that point release upgrades from 14.2-RELEASE to 14.3-RELEASE should be "complete no brainers"? Why do we need to have a PHD in FreeBSD mechanics in order to install an NVidia driver on a "release point upgrade" on FreeBSD?

I have the time to spend literally "weeks" figuring this out... but my guess is that other FreeBSD users are not going to bother to do that (now or in the future).
Click to expand...
Well, x11/nvidia-driver* pkg built against 14.2 could run on 14.3, while graphics/nvidia-drm-*-kmod[-devel] SHOULD NOT.

This is because x11/nvidia-driver* relies on relatively stable FreeBSD KBI, while graphics/nvidia-drm-*-kmod[-devel] relies on quite quite and quite unstable LinuxKPI.ko KBI via corresponding graphics/drm-*-kmod.

Just my understanding, but Linux is far less considering backward compatibilities compared with FreeBSD.
 
T-Aoki said:
Well, x11/nvidia-driver* pkg built against 14.2 could run on 14.3, while graphics/nvidia-drm-*-kmod[-devel] SHOULD NOT.

This is because x11/nvidia-driver* relies on relatively stable FreeBSD KBI, while graphics/nvidia-drm-*-kmod[-devel] relies on quite quite and quite unstable LinuxKPI.ko KBI via corresponding graphics/drm-*-kmod.

Just my understanding, but Linux is far less considering backward compatibilities compared with FreeBSD.
Click to expand...

I get what you are writing...

The "User experience" on this is terrible for FreeBSD.

Users should not have to understand that "Well, it's just not going to work". They do not care about "What does not work", they care about "What works".

This should have 100% worked when they upgraded using pkg. I mean seriously, it's a FreeBSD "point release" not a major release. You don't sink the entire ship on a point release. If you are releasing a "point release" that does this... then there is something "wrong with the point release" and the point release should not have been released in the first place.
 
CShell said:
I get what you are writing...

The "User experience" on this is terrible for FreeBSD.

Users should not have to understand that "Well, it's just not going to work". They do not care about "What does not work", they care about "What works".

This should have 100% worked when they upgraded using pkg. I mean seriously, it's a FreeBSD "point release" not a major release. You don't sink the entire ship on a point release. If you are releasing a "point release" that does this... then there is something "wrong with the point release" and the point release should not have been released in the first place.
Click to expand...
Anyway, I've done what I can currently on PR 288314. Now it's on admins of kmod pkg builders to accept or not. If not accepted, I have no other way for this at least for now, unfortunately.
It's not on my hand right now.
 
Wow, I just looked through the PR and it seems a lot of work, hence the thanks for your post above. I understand the comment by CShell, but I do kind of think, at present, that the typical FreeBSD user is a bit more advanced.

But, I don't know, of course. It's always difficult to figure out what others think.

While I agree with T-Aoki that most people skip pkg messages maybe a note in /usr/ports/UPDATING as it is a common issue-- at least once I had the issue, searched the forums and found my own post about solving it the last time is a reasonable temporary solution?
 
My understanding about /usr/ports/UPDATING (same as /usr/src/UPDATING, too) is that the place is to alert some "additional / unusual" things are needed to upgrading specific ports.

For infrastructual changes that affect porters and committers are in /usr/ports/CHANGES (nothing corresponding with /usr/src).

As the above are not so frequently happenes, those are "mostly" (not perfectly) sane. But if including info about "first installation", it would make them too bloated to chase. So I think "how to make each pkg-message to be read in timely manner" is quite important.
 
I think what's missing in this discussion is... I (DID NOT) upgrade my FreeBSD system from 14.2-RELEASE to the 14.3-RELEASE. I did (TRY) to upgrade my installed FREEBSD system from 14.2 to 14.3 - but once that FAILED I switched to a completely new clean install of FreeBSD 14.3.

I created a 14.3-RELEASE CD downloaded from the FreeBSD releases page -- and installed FreeBSD 14.3 -- overwriting my entire previously installed FreeBSD system. This is an absolute CLEAN INSTALL of a completely new FreeBSD 14.3 system... from CD. (SEE my original post install instructions - above)

=> AND THAT DID NOT WORK <=

... because even when you perform a COMPLETELY NEW INSTALL of the 14.3-RELEASE from CD - pkg upgrade will downgrade all of the installed (and working 14.3) NVidia drivers back to the (now broken) 14.2-RELEASE NVidia drivers.

I (KNOW) this happens because I (literally) just ran (right now - 8/22/2025) pkg upgrade and pkg wanted to downgrade all of my drivers back to 14.2. I have thus pkg lock all of my newly installed (14.3 NVidia drivers) so that they don't get stepped on.

So I don't know what's going on there... but something is not right.
 
T-Aoki said:
Anyway, I've done what I can currently on PR 288314. Now it's on admins of kmod pkg builders to accept or not. If not accepted, I have no other way for this at least for now, unfortunately.
It's not on my hand right now.
Click to expand...

Fair enough - and Thank You ! I hope that someone will pay attention to the hard work you have done.
 
You must log in or register to reply here.
Back
Top