Created attachment 248434 [details] Patch to update for 535.154.05 Update x11/nvidia-driver and x11/linux-nvidia-libs to 535.154.05. Currently tested only on stable/14. Release information: https://www.nvidia.com/Download/driverResults.aspx/217149/en-us/ Attached patch includes support for building / installing latest beta branch driver 550.40.07. https://www.nvidia.com/Download/driverResults.aspx/218121/en-us/ In 550 series of linux driver bumped 2 libraries async from DISTVERSION, so addidional support was needed. Note that although Release Highlights of 550.40.07 states "Added support for nvidia-drm on FreeBSD via linuxkpi.", nvidia-drm.kmod is not built with this. Further investigation is needed, but it beyonds me at least for now. And considerations for migrating graphics/nvidia-drm-*-kmod or not would be required once 550 or newer driver becomes production in the future.
danfe@ as assignee? <https://www.freshports.org/x11/nvidia-driver/> danfe@ <https://www.freshports.org/x11/linux-nvidia-libs/> x11@
(In reply to Graham Perrin from comment #1) It's entangled. Both ports should be needed in sync, but with different maintainers. Moreover, for users of graphics/nvidia-drm-*-kmod, it should be in sync, but another maintainer, ashafer. As ashafer wrote at Forums [1], he would be working on how to handle distfiles once 550 or later series of driver becomes production. [1] https://forums.freebsd.org/threads/call-for-testing-nvidia-drm-kernel-module.87161/page-3#post-643094
Added a branch for 535.154.05 in the repo so you should be able to bump the makesum to use it. And yes as I noted in the forums I plan on redoing the nvidia-drm ports to build straight from the release tarball and avoid the github repo entirely finally.
(In reply to Austin Shafer from comment #3) Thanks for your update! Could confirm distfiles are fetchable. I can prepare the patch for graphics/nvidia-drm-510.kmod and graphics/nvidia-drm-515-kmod, but cannot even try building for now, as I'm waiting for ABIs of LinuxKPI affecting graphics/drm-*-kmod ports to be stabilized enough. Why I'm waiting is that many times, at past, I saw timeframes graphics/drm-*-kmod stop working, even worse, failing to build after LinuxKPI updates until graphics/drm-*-kmod ports successfully chase che change. I don't want such a unfortunate timeframe, as I almost never experienced such a situation on x11/nvidia-driver. So, my question is, how do you think about the stability of LinuxKPI ABI/API? Do you consider it stable enough? For a while, I didn't see the problematic timeframes on MLs and Forums. Yes, there are some screams, but later it turned out that they are using official pkg, instead of building from ports for actual kernels they are using. But I still am not enouch sure it is really OK for now. Another reason I cannot test for now is because my poudriere jail is too busy to rebuild everythin I've installed as of recent stable/14 bump. ;-) Thousands of ports are still waiting to be rebuilt.
(In reply to Graham Perrin from comment #1) Graham, from triager's view, which do you prefer: *Single patch containing every updated ports, for convenience to apply and ensuring everything needed are committed at once. *Divided into per-maintainer basis and set "maintainer-feedback?" per patch. Committer who is assigned to commit should need to confirm every patch has "maintainer-feedback+" (or maintainer timeout) and surely commit every patches without any fallouts, preferrably in single commit for build cluster to be sane. I'm going to prepare patch for ashafer's updated distdiles, but wondering which way to go.
Created attachment 248699 [details] Patch to update for 535.154.05 #2 Updated patch to include graphics/nvidia-drm-[510|515|61]-kmod. These are distinfo-only diffs as was previous update. While here, move manpage of x11/nvidia-driver* from under /usr/local/man/man1/ to /usr/local/share/man/man1/. This was not trivial. Editing pkg-plist alone was insufficient, so one extra patch and conditional for it is added. As list of problematic ports on second call for help includes x11/nvidia-driver* only, other ports are untouched with regards to this. Build tested for x11/nvidia-driver[-304|-340|-390|-470]. Installed/ran only with 550.40.07. If needed for maintainer approveal, I can split this monolithic patch into 4, *Updates for x11/nvidia-driver *Move manpage for x11/nvidia-driver* *Updates for x11/linux-nvidia-libs *Updates for graphics/nvidia-drm-*-kmod (distinfo only) [1] https://lists.freebsd.org/archives/freebsd-ports/2024-February/005516.html
Created attachment 248708 [details] Patch for updating to 550.54.14 without graphics/nvidia-drm-*-kmod updates Uploaded patch to update to 550.54.14, as it switched to Production Branch. Including updates for x11/nvidia-driver and x11/linux-nvidia-libs only for now, as graphics/nvidia-drm-*-kmod needs ashafer's work. For anyone using graphics/nvidia-drm-*-kmod, previous patch is not obsoleted. Both patches not yet obsoleted contains fix for relocation of manpages under /usr/local/man/ into /usr/local/share/man/. Tested on stable/14, amd64 at commit 81be5a55d9bb8717e280433cd8927dfe9bf9b814.
Changed Summary: field to reflect that 550.54.14 is now Production Branch driver.
Here's the nvidia-drm update: https://reviews.freebsd.org/D44073 Certainly am excited to jump to 550 and be done with the github nvidia-drm repo.
(In reply to Austin Shafer from comment #9) Thanks! Users who need to use should visit FreeBSD Phablicator linked at Comment #9 by Austin, download patch for graphics/nvidia-drm-*-kmod ports by clicking "Action" button -> select "Downloaad Raw Diff" and save displayed page as diff. No need to register for download diff only, but need to register if you want to leave comments there. So I'll obsolete previous patch for 535.154.05. BTW, I've left an inline comment on D44073 about supported ${OSVERSION} of stable/14 for graphics/nvidia-drm-61-kmod, as limited range of ${OSVERSION} for stable/14 are now stated to be supported by graphics/drm-61-kmod after commit ports e04b01217828bf06d36a02ad8e69dbb54c30b607.
Comment on attachment 248699 [details] Patch to update for 535.154.05 #2 Obsoleted because support for 550.54.14 is on review and available at differential revision D44073 on Phablicator by Austin Shafer.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=fbde2bdc53a59e3d9190ff4653e20e0678ba012f commit fbde2bdc53a59e3d9190ff4653e20e0678ba012f Author: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> AuthorDate: 2024-02-27 18:26:11 +0000 Commit: Gleb Popov <arrowd@FreeBSD.org> CommitDate: 2024-02-27 18:29:01 +0000 x11/nvidia-driver, x11/linux-nvidia-libs: Update to 550.54.14 PR: 277028 Approved by: danfe (via Telegram) x11/linux-nvidia-libs/Makefile | 27 +++++++++++++++++++++------ x11/linux-nvidia-libs/distinfo | 6 +++--- x11/linux-nvidia-libs/pkg-plist | 4 +++- x11/nvidia-driver/Makefile.version | 2 +- x11/nvidia-driver/distinfo | 6 +++--- 5 files changed, 31 insertions(+), 14 deletions(-)
There is a reported panic from 550.54.14 in bug 277364.
(In reply to Sean Farley from comment #13) I also confirm the panic - added my own comment - seems to only happen if this version of the driver is loaded via /boot/loader.conf
(In reply to Alex from comment #14) Do not attempt to load recent graphics drivers including x11/nvidia-driver. You should load drivers REALLY, REALLY and REALLY ESSENTIAL TO BOOT BASE SYSTEM in /boot/loader.conf[.local]. All others should be loaded via kld_list variable in /etc/rc.conf[.local]. THIS IS NOT A BUG BUT LIMITATION OF LOADER. As you posted more detailed reply to Bug277364Comment7, you should already read my comment there, Bug277364 Comment2. That's all. The amount of memory which loader can load kernel and modules before kernel starts is limited, and kernel and modules becoming larger and larger. On the other hand, once control is passed from loader to kernel, kernek can allocate needed memories to load modules by itself. This is how kld_list works. I've bitten by the limitation much earlier, as I'm using ZFS and zfs.ko is large, too. When i've first bitten by the limitation at the first time, the limited memory was much smaller than it is now, thus zfs.ko, which was even smaller than now, didn't remain enough free area to load (smaller than now) nvidia.ko. After that, the limit was bumped to allow kernel and REALLY FUNDAMENTAL modules to be larger, but at the same time, loading non-fundamental-to-boot-base-system modules are discouraged to be loaded in /boot/loader.conf[.local] and encouraged to load them via kld_list in /etc/rc.conf[.local]. Again, DON'T ATTEMPT TO LOAD THIS VIA /boot/loader.conf[.local] ANYMORE.