FreeBSD Status Report Second Quarter 2025

11 min read Original article ↗

Updates to kernel subsystems/features, driver support, filesystems, and more.


Audio Stack Improvements

I have been working on the audio stack since 2024Q1. Below is a list of the previous status reports:

  • More sound(4) cleanups, fixes and improvements.

  • Committed sndctl(8) (previously mentioned as audio(8)).

  • Committed AFMT_FLOAT support.

  • More out-of-the-box laptop support.

  • Gave up on the /dev/dsp as a router device patch in favor of D50070 (includes relevant discussions).

  • Submitting series of patches to clean up the MIDI subsystem, and working on refactoring it into a generic layer, similar to PCM.

  • Gave BSDCan 2025 talk (slides).

Future work includes:

  • Port virtual_oss to base.

  • More bug fixes, support, optimizations and general improvements, in all areas of the sound stack.

You can also follow the development process in freebsd-multimedia@, where I post regular reports.

Sponsor: The FreeBSD Foundation


DRM drivers

DRM drivers are kernel drivers for integrated and discrete GPUs. They are maintained in the Linux kernel and we port them to FreeBSD. As of this report, we take the AMD and Intel DRM drivers only (NVIDIA FreeBSD drivers are proprietary and provided by NVIDIA themselves).

We port them one Linux version at a time. This allows us to ship updates more often and it eases porting and debugging because we have a smaller delta compared to a bigger jump skipping several versions.

This quarter, we finally merged the drivers from Linux 6.7 and 6.8 that were done during the first quarter into drm-kmod. The porting for DRM drivers from Linux 6.9 was finished and is now ready for review and testing; see the pull request for instructions if you want to try them. The pull request also lists all the patches needed to linuxkpi, the Linux drivers compatibility layer in the FreeBSD kernel. Several patches were already reviewed but there is still work.

These updates target the FreeBSD 15-CURRENT development branch for now. Once kernel patches are accepted and the DRM drivers updates merged, we will evaluate if/how we can backport the kernel patches to earlier release branches (namely 14-STABLE).

While waiting for review, we also started to work on two features which were unsupported on FreeBSD:

They are apparently required to allow the use of wlroots-based Wayland compositors with the Vulkan API (see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286311). wlroots will need a patch as well because it only expects these features on Linux for now.

Both pull requests as well as the patches to linuxkpi they rely on are ready for review and testing. The linuxkpi patches are linked in the pull requests.

This work is kindly sponsored by the FreeBSD Foundation as part of the Laptop and Desktop Project.

Sponsor: The FreeBSD Foundation


Suspend/Resume Improvement

Suspend-to-idle and support for S0ix sleep is in the process of being added to FreeBSD.

This will allow modern Intel and AMD laptops (e.g. AMD and newer Intel Framework laptops), some of which do not support ACPI S3 sleep, to enter low power states to increase battery life.

The USB4 driver (which was a dependency to S0i3 entry) has been updated to allow for the sleep routines, and all CPUs are now entering C3 during s2idle. Scheduler work is needed to ensure CPUs stay in C3 and do not get work scheduled to them, but a prototype solution exists and is working. This means that S0i3 can now be entered on the Framework 13 AMD Ryzen 7040 series laptops, albeit only on my working 14.1 branch. This does not work on -CURRENT yet.

The amdgpio driver (for the AMD GPIO controller) has been extended to service all GPIO interrupts and suspend the controller, as that was potentially a blocker for the CPU to enter S0i3. Nothing is being done with these GPIO interrupts at the moment as FreeBSD does not have the infrastructure for device drivers to register these interrupts on x86 yet.

The SMU idlemask is also now being exported as a sysctl now (dev.amdsmu.0.idlemask), the value of which is not documented and is mostly to help AMD debug issues with S0i3 entry on FreeBSD on their side.

A pre-built image is being built to aid in easily testing S0i3 entry on machines.

With respect to the links, the blog post entry is outdated. A talk was given about this at BSDCan 2025 too, but it has yet to be uploaded as a standalone video; it will be included in the next status report.

Sponsor: The FreeBSD Foundation


Named attribute support (Solaris style extended attributes)

Named attributes is the NFSv4 term for what is also known as Solaris style extended attributes. Since ZFS has its origins in Solaris, the wiring for these exists in OpenZFS. This little project consists of connecting that wiring up. This is not intended to replace the extended attribute support already in FreeBSD. It provides an alternate mechanism for manipulating extended attributes that will be supported for ZFS and NFSv4. There are a few reasons I think this could be useful (as indicated via email discussion). This mechanism allows for extended attributes as large as any regular file, which can be partially updated. Some NFSv4 clients, such as MacOS and Windows, can use these extended attributes but not the FreeBSD/Linux style ones. (I think MacOS calls these extended attributes fork files and Windows calls them alternate data streams.) There is software, such as bash, that know how to manipulate these extended attributes.

The fundamental difference is that this mechanism provides a directory that is not in the file system’s namespace, but is associated with a file object. This named attribute directory can then be read via readdir(3) to get the list of extended attributes, which are really just regular files. These extended attributes are then read/written like any regular file.

The top level system call interface is open(2)/openat(2) with the new O_NAMEDATTR flag (called O_XATTR on Solaris).

Most of the work has been committed to FreeBSD’s main for FreeBSD 15. Once the ZFS patch makes it through review and gets pulled into OpenZFS, the ZFS and NFSv4 support should work. There are also a couple of manual pages currently under review in phabricator.

The main thing left to do is update libarchive/tar so that large extended attributes can be archived/retrieved. (The current FreeBSD extended attribute mechanism is supported by libarchive, but will have size constraints.)


Packrat — NFS client caching on non-volatile storage

NFSv4.1/4.2 provides support for a feature called delegations. When a NFSv4.1/4.2 client holds a delegation, the client has certain rights to a file, including a guarantee that no other client will make changes to the file unless the delegation is recalled. As such, when a client holds a delegation for a file, it can aggressively cache the file’s data, knowing that it will not be modified by other clients until it returns the delegation.

This project is intended to allow the NFSv4.1/4.2 client to aggressively cache file data on client local non-volatile storage, when the client holds a delegation for the file. I created a patch long ago to try and do this for NFSv4.0, but it was never at a stage where it was worth using. This project is a complete rewrite of the patch, done in part because NFSv4.1/4.2 plus other recent NFSv4 related changes makes doing this more feasible.

The patch is getting stable now, but I am not sure if it will be ready for inclusion in FreeBSD 15 as an experimental feature enabled via a new mount option called "packrat".

The main thing I still need to do is code a writeback kernel thread. Right now, dirty chunks stored on client local non-volatile storage get written back to the NFSv4.1/4.2 server upon umount. This can result in the umount taking a long time (as in many minutes). To alleviate this, I am planning on implementing a writeback kernel process that will walk the non-volatile storage and write the dirty chunks back. The trick is to make it aggressive enough that most dirty chunks have been written back when a umount is done, but not so aggressive that it impedes the performance of synchronous NFSv4.1/4.2 RPCs.

This will be very much an experimental feature, but it is hoped it will allow NFS mounts to be used more effectively, particularly in WAN situations, such as a mobile laptop.

There is still work to be done, particularly with respect to recovery of delegations after a NFSv4.1/4.2 client restart.


LinuxKPI 802.11 and Native Wireless Update

This report focuses on the efforts using permissively licensed Linux wireless drivers, mostly unmodified, on FreeBSD, as well as preparing the native net80211 stack for support of newer standards.

As announced iwlwififw(4) was removed from the source tree in favor of a ports/package based solution. Users are asked to use fwget(8) to automatically install the firmware along with any possible configuration.

FreeBSD 14.3-RELEASE is the first release with VHT (802.11ac) support available. Modern iwlwifi(4) chipsets are supported. There was some fallout after the release and a few open problems, but also a lot of positive feedback.

rtw88(4) saw a fix for a NULL pointer in the driver and is now starting to be usable. Thanks to everyone who helped track this down and test patches along the way.

Work on suspend and resume for LinuxKPI-based wireless drivers was picked up again, and we are getting closer to a working solution (at least for suspend it now exists).

Work is also ongoing for Mediatek mt76-based PCIe card support.

HE (802.11ax) definitions were migrated from linuxkpi(4) to native net80211 code and corrected. ifconfig(8) was enhanced parsing more information elements to aid debugging. Work is in progress to fix a problem with reporting signal strength and dealing with RSSI.

Further fixes to LinuxKPI and resolving the problems we worked around by improving native net80211 code are in the works.

Lastly, various man pages were improved or written.

Sponsor: The FreeBSD Foundation


USB Kernel Debugging

XHCI USB controllers offer a mode which allows them to be used as a system debugging interface. XHCI debug uses a special USB 3 cable with VBUS, D+ and D- disconnected. The feature can be used to live debug the FreeBSD kernel, enabling investigation of issues which cause the system video console to lock up and there is not an alternative such as a serial console. This can happen when debugging issues with graphics drivers.

Hiroki Sato developed support for the XHCI debug interface and made it available as some in progress git branches. This implementation enables FreeBSD to operate as both a Debug Host and a Debug Target, with support for debugging from the loader through to the kernel.

I have been updating and testing this support along with Mitchell Horne and together we have a WIP branch which applies to FreeBSD main. We are currently tidying up interfaces and testing for stability with the goal of introducing XHCI debug once 16 is branched.

In doing the XHCI debug work I rediscovered a second form of kernel debugging implemented by Hans Petter Selasky (hselasky@) in 2009. The FreeBSD USB stack supports using a USB serial device as a system console and includes support to continue polling the interface once the system has entered the debugger (such as during a panic). USB Serial debugging allows a developer with two commodity USB serial interfaces to connect to a FreeBSD target and debug the kernel. USB Serial debugging is available in all FreeBSD releases in FreeBSD 9, but changes in the kernel build process mean that it is not detected in modern kernels.

In this quarter I have been working on documentation required to use this interface and changes to make it available in GENERIC kernels for newer FreeBSD releases.

A core part of this work has been trying to document kernel debugging interfaces. If you use live debug interfaces other than serial or network debugging please get in touch so I can add these to the FreeBSD Developers Handbook.

Sponsor: The FreeBSD Foundation


Porting HFS+ to FreeBSD

HFS+ (Hierarchical File System) is a legacy filesystem introduced by Apple for its BSD-based XNU operating systems. Although HFS+ has been deprecated in favor of APFS, it is still in use on many older Apple devices, such as iPods, which rely on HFS+ volumes for storage.

While many modern operating systems include native support for HFS+, FreeBSD currently offers only limited functionality via FUSE. This project aims to address that limitation by porting the original, now open-sourced HFS+ implementation to the FreeBSD kernel as a native filesystem driver.

The primary focus of this effort is to modernize the VFS layer to align with current FreeBSD interfaces and to adapt XNU-specific logic to their FreeBSD equivalents.

Features implemented:

  • Mount support for HFS, HFS+ Volumes

  • Read, stat support for directories and files

  • Create support for directories and files

  • mount_hfs binary