Bug 282312 - x11/nvidia-driver: Update to 550.127.05 with x11/linux-nvidia-libs and related DRM ports
Summary: x11/nvidia-driver: Update to 550.127.05 with x11/linux-nvidia-libs and relate...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Kevin Bowling
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-10-24 22:02 UTC by Tomoaki AOKI
Modified: 2024-10-30 03:26 UTC (History)
5 users (show)

See Also:


Attachments
Patch to upgrade to 550.127.05 (10.79 KB, patch)
2024-10-24 22:12 UTC, Tomoaki AOKI
no flags Details | Diff
Patch to upgrade to 550.127.05 rev2 (chase drm-515-kmod and drm-61-kmod) (11.15 KB, patch)
2024-10-25 21:16 UTC, Tomoaki AOKI
no flags Details | Diff
Patch to upgrade to 550.127.05 rev3 (chase drm-515-kmod and drm-61-kmod #2) (10.74 KB, patch)
2024-10-26 10:07 UTC, Tomoaki AOKI
no flags Details | Diff
Patch to upgrade to 550.127.05 rev5 (Fix version check, workaround clang19) (11.34 KB, patch)
2024-10-27 11:05 UTC, Tomoaki AOKI
no flags Details | Diff
Patch to upgrade to 550.127.05 rev6 (Fix workaround for clang19) (11.38 KB, patch)
2024-10-29 11:11 UTC, Tomoaki AOKI
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tomoaki AOKI 2024-10-24 22:02:31 UTC
Update x11/nvidia-driver, x11/linux-nvidia-libs, graphics/nvidia-drm-510-kmod, graphics/nvidia-drm-515-kmod and graphics/nvidia-drm-61-kmod to latest production branch of nvidia proprietary driver, 550.127.05.

Release Highlights:
  Fixed a bug which could cause applications using GBM to crash when running with
  nvidia-drm.modeset=0.

Not written in Release Highlights, but this should address CVE‑2024‑0126 [1]

Local patch files/patch-nvidia-drm-conftest.h in graphics/nvidia-drm-[515|61]-kmod
turned out to be needed for graphics/nvidia-drm-510-kmod, at least for building on recent stable/14, to build.

And allow building/installing latest Beta branch of driver 565.57.01.
(Some libraries are bumped, and now incorporates files/patch-nvidia-drm-conftest.h in graphics/nvidia-drm-[515|61]-kmod already applied.

[1] https://nvidia.custhelp.com/app/answers/detail/a_id/5586
Comment 1 Tomoaki AOKI 2024-10-24 22:12:18 UTC
Created attachment 254495 [details]
Patch to upgrade to 550.127.05

Patch to upgrade to 550.127.05.
Tested on stable/14 at commit 089664a8db2e16493a4e976939c2237d43f81ada, amd64 only.

Note that actual installed and ran for 550.127.05 and 565.57.01
x11/nvidia-driver
x11/linux-nvidia-libs
graphics/nvidia-drm-61-kmod

and graphics/nvidia-drm-510-kmod and graphics/nvidia-drm-515-kmod are just built.

As fixes for CVE are included in above 2 versions, I decided to omit tests some tests I usually do (i.e. test on main) for filing this earlier.
Comment 2 Nuno Teixeira freebsd_committer freebsd_triage 2024-10-25 13:13:07 UTC
Assigning to maintainer that is committer.
Comment 3 Austin Shafer 2024-10-25 14:43:11 UTC
Thanks for putting this together, these changes LGTM.

Fwiw the unified drivers are so similar that I would assume any CVEs apply to both Linux and FreeBSD. I'm not sure why we don't mention FreeBSD as well but meh.

I'd also be curious to hear about any testing anyone outside of myself has done with 560 or 565. I know we want to keep the ports on the latest production version but a lot has been introduced since 550 and whenever we jump to the next production branch it will be very different, especially regarding Wayland. I haven't observed any issues but jumps that large without hearing anything good or bad from users makes me a little nervous.
Comment 4 Tomoaki AOKI 2024-10-25 16:06:41 UTC
(In reply to Austin Shafer from comment #3)
Well, it is my main concern when I submit patches. Some would need New Feature Branch or BETA branch of drivers for supporting recent GPUs they have in hand.
And some would need new features like GSP firmwares.
Of course, newer drivers could include fixes not documented in Release Highlights, which are almost all the info about drivers for non-nvidia-insider like me can obtain.

What I usually check to create patch (other than distinfos and x11/nvidia-driver/Makefile.version) is bumps/additions/deletions of what are staged.
Note that I basically don't re-enable any of files someone other than me commented out from pkg-plist not to break existing installations I cannot even test.

And the only nvidia GPU I can test upon is Pascal generation Quadro P1000 (notebook), which means I cannot test GSP firmwares. (Introduced NVVERSION check whether GSP firmware modules should be installed or not in my previous, already landed patch, though.)
Comment 5 Kevin Bowling freebsd_committer freebsd_triage 2024-10-25 17:33:19 UTC
(In reply to Austin Shafer from comment #3)
Do you think we should be carrying the new feature branch in ports as well?

I have used drivers from new feature and stable branch for over 10 years on FreeBSD and can only remember a small number of problems, usually related to the lethargy of updating the port or major compiler and API changes.
Comment 6 Austin Shafer 2024-10-25 18:32:07 UTC
It would definitely be nice to have an "nvidia-latest" port or some similar name that grabbed the latest feature branch. You're right that GSP Firmware and new GPU support are examples of why users might want this. My only concern is that it would increase the packaging effort spent on nvidia-driver if we introduced a flavor like this.

That being said Tomoaki has helpfully been submitting updates to provide support for the latest drivers. If we can do a better job of merging them in a timely fashion, users can build nvidia-driver from ports themselves and specify whatever recent version they want. It's a little work but some users already do this so we can just make sure the compatibility is there for it. Outside of patch review and maintainer approval that shouldn't increase the maintenance burden. I'd be pro this as a start.
Comment 7 Tomoaki AOKI 2024-10-25 21:16:30 UTC
Created attachment 254515 [details]
Patch to upgrade to 550.127.05 rev2 (chase drm-515-kmod and drm-61-kmod)

Update patch to chase updates of graphics/drm-515-kmod [3] and graphics/drm-61-kmod [4]. Fixed distinfo. Note that graphics/drm-510-kmod is not updated.

Intentionally kept previous patch for anyone not yet updated ports tree icnluding and after [3].

Tests are done for build only on stable/14, amd64, as I cannot reboot my computer for now.

[3] https://cgit.freebsd.org/ports/commit/?id=ef259f3eeafc2e910cb079986defb85bb2ad4f8c
[4] https://cgit.freebsd.org/ports/commit/?id=a247eb9392542aeb11dc6d13778b59bb4bce2d19
Comment 8 Austin Shafer 2024-10-26 01:49:54 UTC
New version looks good as well.

Kevin are you able to commit this, or do you know who else should sign off on it? The updates to chase drm-kmod fix build issues help fix the nvidia-drm-61-kmod build.
Comment 9 Tomoaki AOKI 2024-10-26 03:44:37 UTC
(In reply to Austin Shafer from comment #8)
If you or Kevin belong to x11@ (group maintainer of x11/linux-nvidia-libs), approval of danfe@ alone is needed for x11/nvidia-driver part.

Otherwise, approval by anyone in x11@ for x11/linux-nvidia-libs part is needed, too. (As graphics/nvidia-drm-*-kmod parts are already approved by you.)

If needed, I can split the 2nd patch into 2, one for chasing graphics/drm-515-kmod and graphics/drm-61-kmod, and another for remaining parts.

But feel free not to wait me.

In this case, once I find the first part (distinfo updates for fixing breakage) is committed, I'll update the 2nd part and replace rev2 of the patch.
Comment 10 Tomoaki AOKI 2024-10-26 04:21:25 UTC
(In reply to Austin Shafer from comment #6)

Well, it would be nice for anyone who want New Feature Branch or BETA Branch of drivers.

But there are some difficulties not to touch x11/nvidia-driver and x11/linux-nvidia-libs.

These 2 are master ports for legacy drivers and legacy drivers just sets DISTVERSION, PORTREVISION, MASTERDIRMASTERDIR and PKGNAMESUFFIX, then includes ${MASTERDIR}/Makefile. Then master port handles everything. (Plenty of conditionals and reinplaces, as danfe@ doesn't want local patch files to increase.)

And as we discussed on past PR or Forums, usual overriding of DISTVERSION doesn't work for graphics/nvidia-drm*-kmod ports and need editing x11/nvidia-driver/Makefile.version. (Otherwise, pkg version is changed as specified but actually built with x11/nviida-driver part with the version in x11/nvidia-driver/Makefile.version, thus, doesn't work.)

Putting above aside, possibly splitting distinfo per version and let master ports' Makefile to choose specified one could help graphics/nvidia-drm-*-kmod ports when graphics/drm-*-kmod and/or x11/nvidia-driver are updated.

Deleting distinfo from graphics/nvidia-drm-*-kmod, merging distinfo of x11/nvidia-driver and corresponding graphics/drm-*-kmod into ${WRKDIR} at pre-fetch target and using it would make things easier if it works as I imagine (not at all tested, just an idea).
Maybe OK without splitting distinfo of x11/nvidia-driver, but it could cause unneeded fetch of distfiles for legacy ports (not sure, though).
Comment 11 Tomoaki AOKI 2024-10-26 04:26:13 UTC
Austin and Kevin, did you notice Bug 282308 "nvidia-driver: NVIDIA MEM resource alloc failed"? [5]

I have feeling it's not actually problems on driver (so I wouldn't let it be in "See also") but I have (currently) no more options to suggest.

[5] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282308
Comment 12 Austin Shafer 2024-10-26 04:40:43 UTC
Thanks, since this will need a bit more review I've gone ahead and sent a review for updating nvidia-drm-kmod. That should fix the breakages and this can proceed without being rushed.

https://reviews.freebsd.org/D47290
Comment 13 Kevin Bowling freebsd_committer freebsd_triage 2024-10-26 07:49:32 UTC
(In reply to Austin Shafer from comment #12)
Thanks looks like manu got that in 2716dbb157611eaae6e578d86202d86910026562.  I will wait a couple days for danfe to take a look at this and maybe commit earlier if he does not acknowledge due to the CVE.
Comment 14 Tomoaki AOKI 2024-10-26 08:20:31 UTC
(In reply to Austin Shafer from comment #12)
Thanks!

A question I didn't ask on D47290 (not to delay to be landed).

In graphics/nvidia-drm-[515|61]-kmod ports, the filename in distinfo differs from graphics/drm-[515|61]-kmod.

For example, on graphics/drm-61-kmod,
  freebsd-drm-kmod-6.1.92-drm_v6.1.92_2_GH0.tar.gz
while in graphics/nvidia-drm-61-kmod,
  freebsd-drm-kmod-drm_v6.1.92_1_GH0.tar.gz
but both are fetchable and has the same size and SHA256 hash.

Is there any reason that using different filename?
Comment 15 Tomoaki AOKI 2024-10-26 10:07:59 UTC
Created attachment 254523 [details]
Patch to upgrade to 550.127.05 rev3 (chase drm-515-kmod and drm-61-kmod #2)

Updated patch to chase:
  commit f2a03a6a45607086a94ee1aa9b9b847b0734da6b [6]
  (graphics/nvidia-drm-515-kmod: Bump version after drm-515-kmod update)

  commit 2716dbb157611eaae6e578d86202d86910026562
  (graphics/nvidia-drm-61-kmod: Bump version after drm-61-kmod update)
by manu@. graphics/drm-61-kmod was updated again and the above follows it up.

Note that as I'm still on the way massive poudriere builds, I cannot even test applying this hand-crafted update (2 distinfo only). But would be OK.

[6] https://cgit.freebsd.org/ports/commit/?id=f2a03a6a45607086a94ee1aa9b9b847b0734da6b
[7] https://cgit.freebsd.org/ports/commit/?id=2716dbb157611eaae6e578d86202d86910026562
Comment 16 Tomoaki AOKI 2024-10-26 15:11:21 UTC
(In reply to Tomoaki AOKI from comment #15)
Confirmed rev3 of the patch is applicable after commit 2716dbb157611eaae6e578d86202d86910026562, builds/installs/runs fine as usual (with quite light tests, though) for 550.127.05 and 565.57.01 with graphics/drm-61-kmod on stable/14, amd64, Quadro P1000 (notebook) with iGPU disabled via UEFI firmware.
Comment 17 Tomoaki AOKI 2024-10-27 11:05:08 UTC
Created attachment 254559 [details]
Patch to upgrade to 550.127.05 rev5 (Fix version check, workaround clang19)

Updated patch for:
  *Fix version check in x11/linux-nvidia-libs/Makefike to fix build
   for 560 series of drivers.

  *Workaround build error of graphics/nvidia-drm-*-kmod on LLVM/Clang19
   as suggested for graphics/drm-61-kmod by Benjamin Jacobs [8], with
   modification to fit graphics/nvidia-drm-kmod/Makefile.common.

Note that rev4 of the patch is skipped uploading, as it only included the former fix and another problem happened on testing updated main at commit 439fa16e1fd35181898b61264b205bf3b7103a41, amd64 before uploading it.
Not actually tested with graphics/nvidia-drm-[510|515]-kmod.

As no directly-related commits are done on ports tree since I've uploaded rev3 of the patch, obsoleted broken rev3 of patch.
If anyone requests, I can update the first and rev2 of the patches.
But updating ports tree and apply the latest patch is suggested.

[8] https://lists.freebsd.org/archives/freebsd-current/2024-October/006558.html
Comment 18 Tomoaki AOKI 2024-10-29 11:11:32 UTC
Created attachment 254616 [details]
Patch to upgrade to 550.127.05 rev6 (Fix workaround for clang19)

Update patch for graphics/nvidia-drm+-kmod part:
  Not 100% sure (maybe ccache cached objects on tests before creating patch),
  but rev5 of the patch was wrong. Make variable I used wasn't expanded,
  thus creating directory in wrong place.
  Instead of creating dummy directory on post-patch, remove problematic
  include path with ${REINPLACE_CMD} from ${WRKSRC}/Makefile.

Note that removed include path still exists only on graphics/nvidia-drm-510-kmod.
I've confirmed it buildable on main, amd64, but not installed and ran, as it's old for using on recent main. Let me know if it causes problems on run time for older Releases/stables. I'll add guard for it.
Comment 19 Austin Shafer 2024-10-29 13:50:20 UTC
Thanks for updating with the fixes, I think this looks good.
Comment 20 commit-hook freebsd_committer freebsd_triage 2024-10-29 18:39:56 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=4d5697a5022f9846836a0185bda68557fd6f364b

commit 4d5697a5022f9846836a0185bda68557fd6f364b
Author:     Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
AuthorDate: 2024-10-29 18:24:07 +0000
Commit:     Kevin Bowling <kbowling@FreeBSD.org>
CommitDate: 2024-10-29 18:37:31 +0000

    x11/nvidia-driver, linux-nvidia-libs, nvidia-drm: Update to 550.127.05

    Approved by:    blanket, Austin Shafer <ashafer@badland.io>
    PR:             282312

 graphics/nvidia-drm-510-kmod/distinfo                     |  6 +++---
 .../files/extra-patch-nvidia-drm-conftest.h}              |  0
 graphics/nvidia-drm-515-kmod/distinfo                     |  4 ++--
 .../files/extra-patch-nvidia-drm-conftest.h}              |  0
 graphics/nvidia-drm-61-kmod/distinfo                      |  4 ++--
 .../files/extra-patch-nvidia-drm-conftest.h (new)         | 14 ++++++++++++++
 graphics/nvidia-drm-kmod/Makefile.common                  |  7 +++++++
 x11/linux-nvidia-libs/Makefile                            | 15 ++++++++++++---
 x11/linux-nvidia-libs/distinfo                            |  6 +++---
 x11/nvidia-driver/Makefile.version                        |  2 +-
 x11/nvidia-driver/distinfo                                |  6 +++---
 11 files changed, 47 insertions(+), 17 deletions(-)
Comment 21 Tomoaki AOKI 2024-10-29 21:51:20 UTC
(In reply to commit-hook from comment #20)

Thanks, Kevin!

Wouldn't it be needed to MFH into 2024Q4?
It would need additional approval by portmgr, but as this relates wuth CVE‑2024‑0126 [1] mentioned Description here, it would be wanted.

[1] https://nvidia.custhelp.com/app/answers/detail/a_id/5586
Comment 22 Alexey Dokuchaev freebsd_committer freebsd_triage 2024-10-30 03:26:35 UTC
(In reply to Kevin Bowling from comment #13)
> I will wait a couple days for danfe to take a look at this and maybe commit
> earlier if he does not acknowledge due to the CVE.
Thanks for taking care of it Kevin! I've been mostly AFK these several days and catching up with email just now.  I think I've said it before, but if not: you've been doing great work with nVidia ports and thus don't have to ask or wait for my approval next time.  As the number of nVidia-related ports had increased recently, perhaps they all should be brought under x11@ wing to lower the impedance, I'll look into this.