a few observations with 15-prerelease as of early this week

From: Chris Torek <chris.torek_at_gmail.com>
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.