a few observations with 15-prerelease as of early this week
Date: Sat, 30 Aug 2025 04:05:41 UTC
The mysterious "build failed when process died from signal during
memory pressure" problem seems to be gone. I suspect one of the
VM system fixes that squeezed in between all the memq work,
specifically the copy on write stuff. Specifically:
c9836764199 vm_fault: Defer marking COW pages valid
43c1eb894a5 vm_object: Fix handling of wired map ...
seem like candidates.
I ran into the libcurl issue and had a heck of a time rebuilding
it with the krb5 changes and "git fetch" failing, but a quick
temporary update of the curl port to disable gssapi entirely got
past it. :-)
I am now *sometimes* able to "kldload amdgpu" without having the
console blow up and the system reboot. This is on a 7950-based
system with the iGPU as the console. One problem seems to be that
the amdgpu_device_init() sequence winds up calling dml2_init()
without first invoking DC_FP_START() somewhere in the path. This
means that the kernel uses FPU instructions without having done
the prep work. All of this is specific to the drm-66-kmod AMD GPU
port, though it might appear in earlier drm-*-kmod versions as
well. Even once it's loaded, however, actually firing up X on the
console eventually leads to another crash (perhaps another misuse
of the FPU, but I don't get a crash dump and the screen has
nothing readable before the BIOS resets everything -- I need a
better way to debug this...).
What is the status of https://github.com/freebsd/drm-kmod anyway?
It is very different code-wise, on its master branch, from what
you get in the port tarball. If I work on the FPU enable stuff,
should I hack on the github repo, or code patches for the tarball?
Despite the report of the reproducible zfs crash, overall everything
looks remarkably solid so far.