Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 29 Aug 2025 21:05:41 -0700
From:      Chris Torek <chris.torek@gmail.com>
To:        freebsd-current <freebsd-current@freebsd.org>
Subject:   a few observations with 15-prerelease as of early this week
Message-ID:  <CAPx1GveLjXtNf8GiZ6BHCH5eJfMwt=22mEPaHpk9nxdhd3ey2Q@mail.gmail.com>

index | next in thread | raw e-mail

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.


home | help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPx1GveLjXtNf8GiZ6BHCH5eJfMwt=22mEPaHpk9nxdhd3ey2Q>