Page MenuHomeFreeBSD

x11/nvidia-driver, x11/linux-nvidia-libs, graphics/nvidia-drm*-kmod: Upgrade to latest Production Branch of driver 570.124.04
ClosedPublic

Authored by junchoon_dec.sakura.ne.jp on Mar 5 2025, 1:14 PM.
Tags
None
Referenced Files
F115081175: D49245.diff
Sun, Apr 20, 7:07 AM
Unknown Object (File)
Thu, Apr 17, 2:39 AM
Unknown Object (File)
Mon, Apr 14, 9:37 AM
Unknown Object (File)
Tue, Apr 8, 8:26 AM
Unknown Object (File)
Sat, Apr 5, 2:34 AM
Unknown Object (File)
Mon, Mar 31, 11:00 PM
Unknown Object (File)
Sun, Mar 30, 5:10 PM
Unknown Object (File)
Mon, Mar 24, 1:00 PM

Details

Summary

Found that nvidia released new Production Branch of driver, 570.124.04.
Upgrade corresponding ports for it.

x11/nvidia-driver
x11/linux-nvidia-libs
graphics/nvidia-drm-[510|515|61|66]-kmod

and unlike usual upgrades, to address the issue that X11 cannot acquire modesetting permission,

graphics/nvidia-drm-kmod (Makefile.common)

needs fix.

See
https://www.nvidia.com/en-us/drivers/details/241090/ (FreeBSD native driver)
https://www.nvidia.com/en-us/drivers/details/241089/ (Linux driver for linux-nvidia-libs)
for details.

Also available as Bug285139.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285139

Note that this update (intentionally) doesn't contain VulkanSC support and sandboxing support newly added in Linux version only.

While here, upgrade graphics/egl-wayland to 1.1.18 to match with Linux version.

And for graphics/egl-wayland:
graphics/egl-wayland: update to 1.1.18

Changes: https://github.com/NVIDIA/egl-wayland/releases/tag/1.1.18

		https://github.com/NVIDIA/egl-wayland/releases/tag/1.1.17
		https://github.com/NVIDIA/egl-wayland/releases/tag/1.1.16
		https://github.com/NVIDIA/egl-wayland/releases/tag/1.1.15
		https://github.com/NVIDIA/egl-wayland/releases/tag/1.1.14

Reported by: Library version of the Linux version of driver package

Diff Detail

Repository
R11 FreeBSD ports repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Aside from the one note about the fbdev comment this looks good to me, thanks.

graphics/nvidia-drm-kmod/Makefile.common
49

I think it would be good to expand this note to mention that this is a bug with the drm-kmod fbdev implementation and this will be enabled again when that is fixed.

Expanded comment about the introduced workaround for X11 in graphics/nvidia-drm-kmod/Makefile.common as per request from ashafer. No changes for other parts.

graphics/nvidia-drm-kmod/Makefile.common
49

Updated and reformatted the comment. Does this look reasonable?

This revision is now accepted and ready to land.Mar 6 2025, 3:06 PM

In preparation for review D47742 "kernel linker: Disable local sym
resolution by default" to be landed, commits

f2cc91f4b56eaa5da41a712b3c42be874161c1c9
  (for graphics/[nvidia-]drm-515-kmod)
8b4b66d94b8ff86c1c764094c38273313dd5f2d3
  (for graphics/[nvidia-]drm-61-kmod)
f7f46d1b58279326de0760ce1fee71631af40cae
  (for graphics/drm-66-kmod)

and

e3d1e7c048d0c909e3f67bc4e2dba558f4c17781
  (for graphics/nvidia-drm-66-kmod)

are landed.

To chase these, updated patch for graphics/nvidia-drm-[515|61|66]-kmod.
This patch is updated for distinfo parts only.

Note that commit aa1da009b4081b25bb162b0c4177e872ca0b81a3 does not
affect, as no updates are needed for x11/nvidia-driver/Makefile.

Tested with "debug.link_elf_leak_locals=0" in /boot/loader.conf on:

stable/14, amd64 at commit 7215aed7974cc4b7d3197ca5e5fcf545d3a28c0f
main, amd64 at commit 780a4667bbde0daa90db900bb0f93f6337d6208b

using graphics/nvidia-drm-61-kmod with ports tree at
commit 1a6d0749a55c1e35a42e943429ec043e6a1c625c and X11 started fine.
No tests on other variants and Wayland.

This revision now requires review to proceed.Mar 16 2025, 1:46 AM
This revision is now accepted and ready to land.Mar 17 2025, 1:59 PM

@ashafer you can go ahead and commit this with "Approved by: kbowling(mentor), maintainer timeout (danfe, x11)".

Danfe indicated support for moving this to some quorum, maybe we need an nvidia@ alias or can discuss with x11 shared ownership of all the ports.

@ashafer you can go ahead and commit this with "Approved by: kbowling(mentor), maintainer timeout (danfe, x11)".

Danfe indicated support for moving this to some quorum, maybe we need an nvidia@ alias or can discuss with x11 shared ownership of all the ports.

IIRC x11@ was added as maintainer for nvidia related ports to ease updates and bugs so they are reported on the ML. But since the beginning x11@ never did anything with them and it was implied that nvidia maintainer handle those.

"Btw if anyone updates to the latest 570 nvidia-driver you probably want to set hw.nvidia.registry.EnableGpuFirmware=0 in /boot/loader.conf to avoid breaking suspend/resume. That should work around the problem while I get a fix into a future 570 version"

In the future, can we please have a pkg msg update in the commit if the update includes requirements for a workaround to not break?

The suspend/resume breakage was found after this commit, it wasn't something known before committing or else it would not have landed.

My message from earlier was giving a heads up to something we found this morning. I'm not sure how frequently we update pkg messages or if this is the best place for short-term known issues. There is a build happening for the next 570 release in around a week so I'm hoping to get a fix into that. My plan was to look into the issue for a day or two, if a fix isn't easy then we can add a broader warning to notify users. If people feel strongly that we need an immediate notification of a workaround that we found today then I won't oppose it.

Sir, first of all thank you for your hard work in this project. You do a lot of good stuff that makes a big positive impact around here, and I appreciate you. Second, respectfully, you broke it and it requires a work around in order to not be broken. I told you I would approve documenting this immediately over 20 minutes ago and it could have been in the tree by now, and now you're saying "we're going to defer it to a future fix that we don't even have yet unless I start getting several complaints".

I don't know what to do here sir, I offered my help making it right. As a doc maintainer, being firm about the doc is my responsibility, and if I'm not going to do it, I should step down.

I don't know what to do here sir, I offered my help making it right. As a doc maintainer, being firm about the doc is my responsibility, and if I'm not going to do it, I should step down.

As in quite specific cases that only specific version of drivers works fine on specific configuration of hardware, there are non-zero possibilities that the workaround is worth keeping in long term. (Experienced on different OS [DOS] other than FreeBSD. Older and newer drivers didin't work but single specific version worked fine, IIRC. Would not be a GPU, though.)

Do you think reasonable adding below in pkg-messages (actually, files/pkg-messages.in) of x11/nvidia-driver?
Note that the specified version could be 565.00, as GSP firmwares are started to be provided from 565 series of drivers that are never become Production Branch.

As you may see any of Bug285741, Bug285803 and/or my posts on Mastodon or Matrix introducing these, suspend/resume never worked for me after FreeBSD switched from APM to ACPI, thus, cannot test at all and didn't think there are any working cases with nvidia dGPUs. As far as I can recall, all successful cases for suspend/resume were iGPU-only cases until these 2 PRs are filed.

If you have nvidia GPUs having GPU System Processor (GSP: Turing
or later generations of GPUs have it) and suspend / resume stops
working after upgrading to driver version 570.00 and later,
try adding below in your /boot/loader.conf as a workaround until
upstream fixes it.

hw.nvidia.registry.EnableGpuFirmware=0

Do you think reasonable adding below in pkg-messages (actually, files/pkg-messages.in) of x11/nvidia-driver?
Note that the specified version could be 565.00, as GSP firmwares are started to be provided from 565 series of drivers that are never become Production Branch.

As you may see any of Bug285741, Bug285803 and/or my posts on Mastodon or Matrix introducing these, suspend/resume never worked for me after FreeBSD switched from APM to ACPI, thus, cannot test at all and didn't think there are any working cases with nvidia dGPUs. As far as I can recall, all successful cases for suspend/resume were iGPU-only cases until these 2 PRs are filed.

If you have nvidia GPUs having GPU System Processor (GSP: Turing
or later generations of GPUs have it) and suspend / resume stops
working after upgrading to driver version 570.00 and later,
try adding below in your /boot/loader.conf as a workaround until
upstream fixes it.

hw.nvidia.registry.EnableGpuFirmware=0

This is actually open for review now:
https://reviews.freebsd.org/D49640

@kbowling wrote:

@danfe indicated support for moving this to some quorum, maybe we need an nvidia@ alias or can discuss with x11@ shared ownership of all the ports.

That's right. I've planned on handing all nVidia ports over to some collegial entity for quite a while, but until recently (before Kevin's work) proposed patches often were breaking legacy ports in some way, or simply weren't good enough. As the situation had greatly improved, I guess D49657 should follow along.