Thanks!

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.

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.

Uploaded updated patch (rev6) using option e) at Bug 282312.

Found the root cause in nvidia codes. No need to touch upstream graphics/drm-[515|61]-kmod side.

Intermediate results of option b).
Look for the offending lines after make patch for graphics/nvidia-drm-61-kmod without the workaround by

I've never dug into upstream repo of drm-kmod before, so possibly I'm overlooking or mis-understanding, but tag name drm_v5.10.163_7 (specified by graphics/drm-510-kmod/Makefile.version) still has linuxkpi/dummy/include, so it wouldn't be affected.
So, our options would be:

a) Commit rev5 of the patch at Bug 282312 as-is, and once upstream addressed this issue,
   revert graphics/nvidia-drm-kmod/Makefile.common part of the patch and bump portrevision.

A possibility is that all fixes in drm-kmod upstream are anywhere nvidia-drm-*-kmod builds and left some more that nvidia-drm-*-kmod build picks. The fixes in upstream seems to remove "CFLAGS+= -I${.CURDIR:H:H}/linuxkpi/dummy/include" lines from Makefile here and there, according to commit logs.

In D47290#1078612, @kbowling wrote:

In D47290#1078609, @junchoon_dec.sakura.ne.jp wrote:

In D47290#1078596, @kbowling wrote:

@ashafer_badland.io @manu it seems like there might still be some remaining in drm-kmod, this is still failing for me and @junchoon_dec.sakura.ne.jp

@kbowling, does it still fail with rev5 of the patch at Bug 282312?
It includes workaround in graphics/nvidia-drm-kmod/Makefile.common, obtained from (with a change of a variable to fit with this) freebsd-current ML by Benjamin Jacobs. And it doesn't fail on stable/14 (still clang18), so something changed in clang19 on main (any of new default option, maybe) is causing the issue.

https://lists.freebsd.org/archives/freebsd-current/2024-October/006558.html

No your workaround is good but I think the path needs to be dropped in drm-kmod

In D47290#1078596, @kbowling wrote:

@ashafer_badland.io @manu it seems like there might still be some remaining in drm-kmod, this is still failing for me and @junchoon_dec.sakura.ne.jp

Updated my patch at Bug 282312 as rev3, chasing @manu's commit, for further reviews.
And this review (D47290) can now be closed as of:

Looks good to me.
Once this lands, I'll update my patch at Bug 282312 for further reviews.

Thanks! Now things got clear enough for me.

Tested on

stable/14, amd64 at commit 04a191c251e5ef20deb14fcdcf628a589be5216a

and

main, amd64 at commit 40d951bc5932deb87635f5c1780a6706d0c7c012.

For ports, overriding DISTVERSION with 555.42.02.

If I understand correctly, setting BUILD_DEPENDS alone makes the dependency not to be automatically installed by pkg, including packages which are locally built with poudriere or any other clean-room builders.
Legacy builders like portupgrade should not be affected, though, as it needs BUILD_DEPENDS to be installed first to proceed builds.

Is there any reason to disallow nvidia-drm-61-kmod for whole stable/14 other than that graphics/drm-61-kmod disallows them?
If not, stable/14 having ${OSVERSION} >= 1400508 is now stated to be supported by graphics/drm-61-kmod starting from commit e04b01217828bf06d36a02ad8e69dbb54c30b607 [1].

I should note that anyone using default LLVM (except for powerpc) as external toolchain would be bitten. (Not me, though.)
Default LLVM on ports is still stuck on devel/llvm90 (devel/llvm10 for powerpc only) according to Mk/bsd.default-versions.mk.
Maybe now would be time to switch default LLVM to devel/llvm10 or later (devel/llvm13, which is required by mesa?).

In D35552#807231, @hselasky wrote:

Include all chunks.

In D35552#806924, @hselasky wrote:

Keep trailing space on last line.

Looks and works OK for old (0x100 protocol) ThinkPad.
No new regression on my T420. (Known-not-working and dangerous functions like suspend/resume are untested.)
Not marking as "Accepted" as I don't have newer ThinkPads having 0x200 protocol and no knowledges for 0x200 protocol.
So I just reviewed and tested fallback (to 0x100 protocol) codes.

In D7538#273971, @allanjude wrote:

In D7538#273970, @karl_denninger.net wrote:

I'll try to get some time allocated to that - right now the machine that
I use for this effort is busy doing other things but I may be able to
free up some time on it in the next week or two.

Is there any intent to backport/MFC those changes into 11-STABLE?  That
I can probably test and adapt the code to more-quickly.

The needfree change is a good one, it's just that having it confined to
-HEAD causes problems for me right now due to "free computer of
appropriate configuration" constraints.

Thanks in advance.

• smime.p7s4 KBDownload

I would expect the latest ZFS code to be merged from -current to stable/11 in time for 11.2-RELEASE

Just a heads-up.
r325851 broke this (including Karl's updated patch at bug 187594).
"needfree" in arc.c has gone.

Confirmed that the latest patch Karl uploaded on Bugzilla bug 187594 [1] (merged his patch with the one here) is...

In D7538#260193, @karl_denninger.net wrote:

Being new to phabricator.... how do I upload a diff that is off a (probably) different base rev and has my changes in it (I don't really want to "update" the existing diff, or do I?)

Confirmed. Thanks!
Tested on stable/11 at r304717, amd64, ports tree is at r420859.

Build, install and run: 367.35
Build only: 364.19, 361.45.11, 361.42, 361.28, 358.16, 355.11, 352.79,
            352.55, 352.41, 352.30, 352.21, 349.16, 346.72, 346.59

Now it builds fine and running for stable/11 (r304528) and head (r304535), both amd64.
Thanks!