Update x11/nvidia-driver-470 and x11/linux-nvidia-libs-470 to 470.256.02

[junchoon_dec.sakura.ne.jp]

Summary

Requested updating 470 series of legacy version of driver to 470.256.02 at Bug 285069 - x11/nvidia-driver-470: update from 470.161.03 to 470.256.02 or greater.

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

This update cannot be achieved with simple version overriding and need some fix (following newer series of versions).

Fixed the issue by expanding conditionals for newer series to cover 470.256.02.

Tested (by myself) make and make package only, on stable/14, amd64 at commit 7215aed7974cc4b7d3197ca5e5fcf545d3a28c0f as I myself am not using 470 series of driver anymore.

Additionally, Graham Perrin reported this patch works OK for him on 15-Current at Comment 7 of the PR.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285069#c7

[grahamperrin]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285069#c7 (2025-03-22):

… OK so far, no sense of regression. I'll test with WBINVD=on. …

Also tested:

ACPI_PM=off
DOCS=on
LINUX=on
WBINVD=off

With Plasma set to turn off the screen after two minutes, I sometimes found all displays blank/dark after e.g. moving a trackball. Not turning on, presumably, although they're on after Control-Alt-F2 (vt at ttyv1) and remain on after Alt-F9 (back to Plasma). I can't recall whether I made this power setting, or first found the darkness, before or after beginning to test 470.256.02. I have only one external display at home, I had a vague sense that the symptom was more likely to occur with two external displays.

The photograph below was taken at 06:41 on Sunday. Whilst the clock on the lock screen was wrong (02:33), the system was not frozen. Parts of the screen (probably the white dots) became brighter in response to trackball movement. Again, the workaround was a switch away to a vt, then back.

What's pictured did not strike me as particularly unusual, at this time I don't suspect a regression.

Today (Monday) I'll have an opportunity to compare, to retest at work with two external displays. For comparison, I have temporarily reverted to 470.161.03.1500034_1.

[grahamperrin]

… With Plasma set to turn off the screen after two minutes, I sometimes found all displays blank/dark after e.g. moving a trackball. Not turning on, presumably, although they're on after Control-Alt-F2 (vt at ttyv1) and remain on after Alt-F9 (back to Plasma). … sense that the symptom was more likely to occur with two external displays.

Not a regression with 470.256.02 👍

… Today (Monday) I'll have an opportunity to compare, to retest at work with two external displays. For comparison, I have temporarily reverted to 470.161.03.1500034_1.

The issue recurred less than an hour after beginning to use the usual HP dock at work with two Philips displays on DisplayPort. On each display, the white LED strip (below the PHILIPS logo) pulsed.

After working around:

grahamperrin:~ % date ; uptime ; tail -n 3 /var/log/messages
Mon 31 Mar 2025 10:10:11 BST
10:10a.m.  up 53 mins, 6 users, load averages: 0.97, 1.21, 1.28
Mar 31 10:06:16 mowa219-gjp4-zbook-freebsd kernel: nvidia-modeset: ERROR: GPU:0: Failed to allocate memory for composition pipeline
Mar 31 10:06:18 mowa219-gjp4-zbook-freebsd syslogd: last message repeated 2 times
Mar 31 10:08:27 mowa219-gjp4-zbook-freebsd devd[3069]: check_clients:  dropping disconnected client
grahamperrin:~ % pkg iinfo nvidia-driver-470
nvidia-driver-470-470.161.03.1500035_1
grahamperrin:~ % pkg info nvidia-driver-470 | grep -A 4 Options
Options        :
        ACPI_PM        : off
        DOCS           : on
        LINUX          : on
        WBINVD         : off
grahamperrin:~ %

{F113558343}

[grahamperrin]

… 06:41 on Sunday. Whilst the clock on the lock screen was wrong (02:33), the system was not frozen. …

This also recurred following the downgrade to 470.161.03.1500034_1. So, not a regression with 470.256.02 👍

The nvidia-modeset line below was noted after switching to ttyv0, before a login at ttyv1:

Mar 31 14:23:10 mowa219-gjp4-zbook-freebsd kernel: nvidia-modeset: WARNING: GPU:0: Failed to allocate memory for composition pipeline; continuing with potential tearing.
Mar 31 14:23:58 mowa219-gjp4-zbook-freebsd devd[3069]: check_clients:  dropping disconnected client
Mar 31 14:24:14 mowa219-gjp4-zbook-freebsd login[4244]: ROOT LOGIN (root) ON ttyv1

I'll again upgrade, with a package built using default options.

[ashafer]

@grahamperrin so this "failed to allocate memory" issue happens when you are using displays connected through the HP display dock? Does it ever happen when you are just using the monitors directly connected to the NVIDIA card? Is this a laptop? Those docks have always given me all kinds of problems, the thinkpad dock I have likes to turn one particular monitor of mine off and on randomly.

Since the issue isn't a regression I don't think it should block this review, change seems reasonable to me.

[grahamperrin]

In D49457#1131202, @ashafer wrote:

… Since the issue isn't a regression I don't think it should block this review, …

+1

It seemed prudent to mention the two sets of symptoms at a fairly early stage of testing. When I wrote in the early hours of Monday morning, I didn't imagine that both sets would recur so very soon after (temporarily) downgrading to 470.161.03.1500034_1.

---

For what's now off-topic from the review, Matrix (not Discord) might be ideal: https://matrix.to/#/#FreeBSD:matrix.org. Alternatively https://forums.developer.nvidia.com/c/gpu-graphics/145 or /r/freebsd (tech support posts are disallowed in /r/nvidia). Which would you prefer?

Thanks

[grahamperrin]

For completeness, I'm testing with a GPU for which the 470.⋯ driver is:

• a match at https://www.nvidia.com/en-us/drivers/unix/legacy-gpu/
• not a match at https://www.nvidia.com/en-us/drivers/details/226762/.

IIRC this discrepancy can be negligible.

grahamperrin:~ % pciconf -lv | grep -A 4 vgapci
vgapci0@pci0:1:0:0:     class=0x030000 rev=0xa1 hdr=0x00 vendor=0x10de device=0x0ff6 subvendor=0x103c subdevice=0x2256
    vendor     = 'NVIDIA Corporation'
    device     = 'GK107GLM [Quadro K1100M]'
    class      = display
    subclass   = VGA
grahamperrin:~ %

[junchoon_dec.sakura.ne.jp]

Confirmed landed. Thanks!
BTW, would this be worth MFC'ed to 2025Q2? It branched before this landed.

[grahamperrin]

In D49457#1131891, @junchoon_dec.sakura.ne.jp wrote:

… would this be worth MFC'ed …

Bugzilla triage perspective: https://wiki.freebsd.org/Bugzilla/TriageTraining#Ports_Specific.

Via https://www.nvidia.com/en-us/drivers/unix/freebsd-x64-archive/, for the sets of release highlights after 470.161.03:

• FreeBSD Display Driver – x64 470.182.03 | FreeBSD x64 | NVIDIA
• FreeBSD Display Driver – x64 470.199.02 | FreeBSD x64 | NVIDIA
• FreeBSD Display Driver – x64 470.223.02 | FreeBSD x64 | NVIDIA
• FreeBSD Display Driver – x64 470.239.06 | FreeBSD x64 | NVIDIA
• FreeBSD Display Driver – x64 470.256.02 | FreeBSD x64 | NVIDIA

Whilst most sets did specify bug fixes (highlights for 470.239.06 were relatively nondescript), I was not aware of any corresponding report in Bugzilla for FreeBSD.

---

With only one user of a compatible GPU offering feedback during the test period, a merge to 2025Q2 might be overly optimistic.

https://freshbsd.org/freebsd/ports/branch/2025Q2

I can't guess how many users of quarterly also use this port. https://www.freshports.org/x11/nvidia-driver-470/ does have at least two watchers, however AFAIK numbers are not publicly disclosed.

HTH

[kbowling]

MFH is done at the discretion of the committer, a request by the maintainer, or potentially someone else. I would lean toward no in this case without a supporting reason.

[junchoon_dec.sakura.ne.jp]

Why I've asked whether this should be MFH'ed or not is just because now is the timing almost just after 2025Q2 is branched. Usually for this kind of non-security upgrade, me, too, prefer not MFH'ing.