FreeBSD Status Report Second Quarter 2026

Links:
FreeBSD Foundation URL: https://freebsdfoundation.org/
Technology Roadmap URL: https://freebsdfoundation.org/blog/technology-roadmap/
Donate URL: https://freebsdfoundation.org/donate/
Foundation Partnership Program URL: https://freebsdfoundation.org/our-donors/freebsd-foundation-partnership-program/
FreeBSD Journal URL: https://freebsdfoundation.org/journal/
Foundation Events URL: https://freebsdfoundation.org/our-work/events/

Contact: Deb Goodkin <deb@FreeBSDFoundation.org>

The FreeBSD Foundation is a 501(c)(3) non-profit dedicated to advancing FreeBSD through both technical and non-technical support. Funded entirely by donations, the Foundation supports software development, infrastructure, security, and collaboration efforts; organizes events and developer summits; provides educational resources; and represents the FreeBSD Project in legal matters.

Links:
FreeBSD 15.1-RELEASE announcement URL: https://www.freebsd.org/releases/15.1R/announce/
FreeBSD 14.5-RELEASE schedule URL: https://www.freebsd.org/releases/14.5R/schedule/
FreeBSD releases URL: https://download.freebsd.org/releases/ISO-IMAGES/
FreeBSD development snapshots URL: https://download.freebsd.org/snapshots/ISO-IMAGES/

Contact: FreeBSD Release Engineering Team <re@FreeBSD.org>

The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things.

The Team managed 15.1-RELEASE, leading to the official RELEASE build and announcement in June. Planning has started for the upcoming 14.5-RELEASE, which is due to arrive in September.

The Release Engineering Team continued providing weekly development snapshot builds for the main, stable/15, and stable/14 branches; and also for the stable/13 branch until its End-of-Life at the end of April.

Links:
Cluster Administration Team members URL: https://www.freebsd.org/administration/#t-clusteradm

Contact: Cluster Administration Team <clusteradm@FreeBSD.org>
Contact: Philip Paeps <philip@FreeBSD.org>

FreeBSD Cluster Administration Team members are responsible for managing the machines the Project relies on to synchronize its distributed work and communications.

In this quarter, the team has worked on the following:

Links:
FreeBSD Bugzilla URL: https://bugs.freebsd.org/ Total Open Bugs Over Time URL: https://bugs.freebsd.org/bugzilla/page.cgi?id=showreport.html&type=total_open_bugs_over_time

Contact: Bugmeister <bugmeister@FreeBSD.org>

In this quarter we have decreased the Problem Reports count.

Although we do continue to get patches for the src tree, the majority of patches we receive are for ports. This may be due to the auto-notifier customizations we have implemented.

For the src tree, in the last 180 days we have received 643 new Problem Reports and closed 844. For ports, the count was 3493 in and 4375 respectively.

We do not currently maintain statistics about how many of these actually generate commits, although we do believe the number to be non-trivial.

During the same 180-day period Mark Linimon and Torsten Zuehlsdorff continued to work to triage older Problem Reports. Mark’s work was partly funded by the FreeBSD Foundation in 2025. These results are visible from the last two dips in our Total Open Bugs Over Time graph.

As well, we seem to be getting more attention from various FreeBSD committers this year. Please contact bugmeister if you are interested in helping.

Of course, we still are doing better at triaging PRs than we are generating attention to the ones we already have. Suggestions welcome.

Mark Linimon has taken on the long-term project of making sure that the submitted patches all apply. However, he does not claim to be a QA person and to be able to evaluate their aptness by himself.

The general takeaway is that, with user education, we are getting better-quality Problem Reports this year. In particular, the ones with patches are being tested for applicability within a week or two of their arrival, and corrected if needed.

However, the farther back in time you go, the more problematic the PRs get, especially 2019 and earlier. I suppose this is to be expected. Mark continues to work on these in the background. The current count is 2611. Around 427 of these, mostly from 2019 and earlier, still need further work.

A problem with the setup of the upgrade to Bugzilla 5.2 has been fixed. Light testing showed no meaningful regressions. A bugfix version to 5.2.1 is imminent. Switching to this codebase is intended to be as soon at it is released. It was initially planned for earlier, however, it seemed inadvisable when the release engineering for FreeBSD 15.0 was ongoing, and then got further put off for 15.1.

"patchQA.py" still remains in beta. The patch application code is not up to its task and must be replaced.

The other problem known with patchQA.py is that it does not know the origins of files that are installed into /etc by installworld. There are external shell scripts that are in testing to help automate fixing the data. This may be simpler than trying to write more fragile Python code for this purpose.

We have created many new Bugzilla accounts by user request. The number of new-account requests has increased this year. So far in 2026 we are at 291, which is not quite 2 per day.

It is now a year since we started requiring emailed requests to create accounts, rather than allowing automated requests. By doing so, the spam flood has been reduced to nearly zero.

The other problem that we are monitoring is the huge number of http requests from crawlers. By now these requests far outnumber those from actual FreeBSD users. These are the cause for the sudden slowdowns our users object to. As none of us are professional sysadmins, we would welcome help from someone with professional experience dealing with them.

Thanks to Alexander Ziaee and the many others who have helped to bring us up to our current state.

See also: https://wiki.freebsd.org/Bugzilla/SearchQueries

Links:
Wiki-Admin Team members URL: https://www.freebsd.org/administration/#t-wiki

Mark Linimon stepped back from the wiki-admin role and two committers took over the wiki-admin role.

Short-term, the team will handle account requests etc.

Medium-term, the plan is to help in the structure of the wiki pages.

Long-term, the idea is to migrate away from MoinMoin Wiki to some other wiki software.

Links:
Alpha-Omega — Linux Foundation Project URL: https://alpha-omega.dev
FreeBSD Foundation URL: https://freebsdfoundation.org
FreeBSD Security Information URL: https://www.freebsd.org/security/
EuroBSDCon 2026 URL: https://2026.eurobsdcon.org

Contact: Pierre Pronchery <pierre@freebsdfoundation.org>

This quarter marked the beginning of my participation to Alpha-Omega’s new initiative around AI. The new wave of LLM-assisted disclosures of security vulnerabilities has been hard to miss, and Alpha-Omega is now assisting prominent Open Source ecosystems facing this challenge. This includes FreeBSD, and given the situation, I have volunteered and been accepted into FreeBSD’s security team. My objective there, besides helping with incoming reports where I can, is to understand existing processes and suggest improvements to facilitate and scale operations. This started with a new instance of RTIR, and with an experimental instance of Forgejo for CI/CD and possible leveraging of LLM integration with the security team’s workflow.

On a related note, and in an effort to facilitate compliance with the European Cyber Resilience Act (CRA), pkgconf was imported at version 2.9.93 in FreeBSD’s base system. This now includes spdxtool(1), which supports the generation of Software Bill of Material (SBOM) conforming to SPDX 3.0.1 specification. Together with Tuukka Pasanen, we are offering a framework for review to that effect in D56474, which still requires polishing before import unfortunately.

First, it should be updated to reflect the availability of spdxtool (a patch is already available). More importantly, finding the correct granularity for the amount of SBOM files to generate while fitting FreeBSD’s build system was not easy. This explains the metadata still missing in some cases; we are working on it for an approach as consistent as possible from the start. Lastly, I apologize in advance for the 1.000+ files added to the coming release; hopefully, this will be mitigated by the switch to pkgbase, with which we believe it will fit perfectly. The SBOM files are expected to be automatically provided in the corresponding packages installed, allowing subsequent SBOM tooling to function with the exact knowledge of the system’s status as installed.

In this context, I am glad to announce that Alice Sowerby, Peter Hansteen, and myself are teaming up to host a workshop about CRA compliance for BSD-based systems during the coming EuroBSDCon conference in Brussels, this September 2026. You are welcome to join us there for practical information about CRA compliance in our ecosystem!

Sponsor: Alpha-Omega, The FreeBSD Foundation

Links:
Cyber Resilience Act Readiness URL: https://github.com/FreeBSDFoundation/all-projects/tree/main/Cyber%20Resilience%20Act%20Readiness

The Foundation is running a project through 2026 to actively prepare the FreeBSD Foundation, Project, and the community for the EU Cyber Resilience Act. There are six main areas of focus: Security and Vulnerability Handling, SBOM Toolchain, Public Documentation, Community Legislative Engagement, Public Project Repository, and Communications.

Over Q2 the project has made significant progress on its key goals.

Security efforts have focused on improving vulnerability handling and supply chain readiness through discussions with downstream vendors about reporting processes, Software Bill of Materials (SBOM) usage, and potential funding for compliance work.

The Foundation has also strengthened collaboration with the wider open source ecosystem by participating in Open Regulatory Compliance and OpenSSF activities, joining the OpenSSF as an associate member, attending Open Source Summit North America, and engaging with projects such as Zephyr to share CRA readiness strategies.

The SBOM toolchain work has advanced significantly and is now close to full end-to-end functionality. We plan to publish a technical blog once the remaining work is complete.

The Foundation also created draft CRA guidance for the FreeBSD community and we plan to publish this along with a dedicated section of the Foundation website providing permanent compliance information.

Transparency remained a priority, and the Foundation has published monthly public updates and meeting minutes on the repo linked above. There will be a full day CRA and SBOM tutorial at EuroBSDCon, which we invite you to attend!

Links:
FreeBSD Lua Tools for SBOM URL: https://github.com/illuusio/freebsd-src/tree/freebsd-lua-tools-sbom/share/sbom
FreeBSD pkg-config WIP SBOM files which are base for Pierre Pronchery’s work URL: https://github.com/illuusio/freebsd-src/tree/sbom-pkgconfig-meld/share/sbom
Generate SBOM files as part of the build review URL: https://reviews.freebsd.org/D56474

Open upstream SPDX license identifier PRs:
ATF PR#128 URL: https://github.com/freebsd/atf/pull/128
bmake NetBSD GNATS#60308 URL: https://gnats.netbsd.org/60308
LDNS ISSUE#305 URL: https://github.com/NLnetLabs/ldns/issues/305
Less PR#792 URL: https://github.com/gwsw/less/pull/792
Libarchive PR#3129 URL: https://github.com/libarchive/libarchive/pull/3129
LibCBOR ISSUE#430 URL: https://github.com/PJK/libcbor/issues/430
libedit NetBSD GNATS#60309 URL: https://gnats.netbsd.org/60309
Libevent ISSUE#1864 URL: https://github.com/libevent/libevent/issues/1864
LibPCAP PR#1689 URL: https://github.com/the-tcpdump-group/libpcap/pull/1689
LibUCL PR#386 URL: https://github.com/vstakhov/libucl/pull/386
TCSH Mantis#777 URL: https://bugs.astron.com/view.php?id=777

Contact: Tuukka Pasanen <tuukka.pasanen@ilmi.fi>

The FreeBSD Software Bill of Materials (SBOM) effort has been continued during Q2 2026. This quarter’s focus has been reviewing and updating pkg-config .pc files and adding SPDX-License-Identifier to third-party projects included in the FreeBSD source. This effort will be continued in Q3.

As said, most of the quarter’s work has been dedicated to polishing pkg-config .pc, as these files are needed when generating SPDX 2.2 and SPDX Lite 3.0.1-compatible SBOM files. During this year Pierre Pronchery has been adding other crucial parts like pkgconf to the FreeBSD source. Currently, the biggest effort lead by him on the tooling side is the review of the SBOM generation part of the build, which holds .pc as part of the review. When the review is ready and the source is added to FreeBSD, SBOMs can be created during the building process.

Besides work on .pc, there has also been polishing of The FreeBSD Lua Tools for SBOM, which have been used to create the current set of .pc files and can be used for future updates. These scripts are still somewhat raw and complicated to use but are now in much better shape than before, and there is documentation on how to use them.

Adding SPDX-License-Identifier to third-party repositories is also a work in progress and will proceed in an order that aligns with project maintainers’ preferences. Why are license identifiers being added to third-party projects? There is no simple answer to this question, but the closest explanation is that machine-readable license identifiers help maintain SBOM information in the future.

If you want to help with this effort:

Sponsor: FreeBSD Foundation

Contact: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>

Links:
Website URL: https://sylve.io
GitHub URL: https://github.com/AlchemillaHQ/Sylve
CI URL: https://sylve-ci.alchemilla.io
Discord URL: https://discord.gg/bJB826JvXK

Contact: Hayzam Sherif <hayzam@alchemilla.io>

Sylve is a modern, unified system management platform for FreeBSD. It provides an integrated web interface for managing virtual machines (via Bhyve), Jails, the networking around them, and ZFS storage.

The backend is implemented in Go, while the frontend is built with Svelte. The project emphasizes a minimal system footprint. By default, it does not require any packages outside of the base system.

Optional runtime dependencies, required only when their respective features are used, include:

The port pulls in these dependencies for convenience to the user, but by itself, Sylve needs no dependencies to run.

Links:
Hackathon/202606 Wiki Page URL: https://wiki.freebsd.org/Hackathon/202606
FreeBSD Hackathon Wiki Page URL: https://wiki.freebsd.org/Hackathon

Contact: Joe Mingrone <jrm@FreeBSD.org>

After BSDCan 2026 in Ottawa, some members of the community gathered for a hackathon at Dalhousie University in Halifax, Nova Scotia, Canada. Across the three repositories, 93 commits landed with the tag Event: Halifax Hackathon 202606.

Much of this work is described in separate report entries, but here is a high-level summary. The bulk of the src work focused on CPU power management. Most of it landed in hwpstate_intel(4), which received fixes for several MSR and uninitialized variable bugs, moved the energy performance preference to an 8-bit scale, and replaced thread_lock() and sched_bind() with IPIs. A new cpu_get_pcpuid() KPI was also added and adopted by both hwpstate_intel(4) and hwpstate_amd. A sweep through the ACPI code tightened the types of the sleep and wake event handlers, removed unused disable flags from acpi_cpu, acpi_hpet(4), and acpi_timer, and made the kernel refuse S4 when S4BIOS is not supported. For laptop support, a new hrfkill driver was committed for the airplane key on some Framework laptops, evdev reporting of the microphone mute key was added to acpi_ibm(4), and iichid(4) was changed to always release its interrupt resource. Other src commits touched libusb, libdtrace, libcxxrt, ifconfig(8), sched_ule, and a number of manual pages. In ports, the default Python was switched to 3.12, a new databases/py-oracledb port was added, and a sysutils/consolekit2 change enabled S0ix suspend on 16-CURRENT. The Emacs ports received various updates and improvements; the R, Jenkins, and some bioinformatics ports were updated. The documentation work added a Handbook section on ZFS native encryption, updated the geli encrypted swap instructions, and improved the FDP Primer guidance on generating patches with context.

Here are the raw hackathon commits across the doc, ports, and src repositories.

While most of the time was spent hacking, it was not all work, as the photos show. Participants spent some evenings and half a day on fun.

Sponsor: The FreeBSD Foundation (meal)

Links:
BSDCan 2026 Presentation Slides

Contact: Alfonso Sabato Siciliano <asiciliano@FreeBSD.org>

Parthenope is a modular, two-step installer for FreeBSD, written in Lua.

During this quarter, the project was presented at BSDCan 2026, showcasing its current status, recent improvements, and future directions. The presentation also introduced several new ideas, mockups, and proof-of-concept implementations for future discussion and development, including an out-of-box experience and/or a post-installation configuration workflow.

Since the previous status report and the EuroBSDCon 2025 presentation, several core parts of the installer have been completely refactored or rewritten, including:

The Text User Interface (TUI) frontend is now close to feature-complete, bringing it close to supporting a complete FreeBSD installation. The remaining major components and screens are the partition editor, ZFS configuration, boot configuration, and the network manager.

While it is not yet possible to fully install FreeBSD using Parthenope, development is progressing rapidly toward a functional release. The next steps are:

Parthenope started as a personal project, but it continues to grow thanks to community ideas, feedback, and feature requests, which are always welcome.

Links:
S.M.A.R.T. on GitHub URL: https://github.com/ctuffli/smart

Contact: Chuck Tuffli <chuck@freebsd.org>

FreeBSD has imported a native Self-Monitoring, Analysis, and Reporting Technology (S.M.A.R.T.) utility, smart(8), into the base system, providing lightweight, built-in disk health monitoring capabilities without requiring third-party packages. It was inspired by the diskctl(8) framework proposed at AsiaBSDCon 2016 to create a permissively-licensed S.M.A.R.T. utility addressing licensing and functionality gaps in existing tools.

The utility provides a unified interface for retrieving S.M.A.R.T. data across multiple storage protocols, including ATA, NVMe, and SCSI. It focuses on ease of integration with monitoring tools, providing multiple output formats (tab-delimited fields, JSON, XML) via libxo(3) and allowing users to query specific health attributes.

Contact: Konstantin Belousov <kib@FreeBSD.org>

Links:
sys: add pdopenpid(2) URL: https://reviews.freebsd.org/D57124
link pddupfd(2) https://reviews.freebsd.org/D57163

Following the addition of pdwait(2) and pdrfork(2) system calls, I looked at the other missing features that are requested by application programmers. The largest feature asked for seems to be an ability to obtain a process descriptor for an existing process.

Currently only one file descriptor may reference an internal struct procdesc in kernel, which in part explains why the interface to open the process by pid is not yet done. The work added the ability for procdescs to be pointed to by more than one file. Attributes controlling the procdesc behavior, e.g. the daemon (closing the file does not terminate the process) were moved from procdesc to the file.

This change allowed to extend the procdesc internal interfaces to implement the man:pdopenid(2) system call.

A facility implemented e.g. by the Linux pidfd descriptors is the pidfd_getfd() system call, that duplicates specified file descriptor from the target process, into the caller. The implementation of it for FreeBSD, named man:pddupfd(2) is relatively straightforward once we get the fget_remote(9) helper.

A problem with it started when the algorithm to check for privileges required to allow the operation was developed. The kernel checks the result of p_candebug() to see if something should be allowed that directly accesses programming resources of the remote process. But p_candebug() result is only valid while the target process lock is owned. Besides, p_candebug() denies actions if the target process changes the executing program with man:execve(2), which might change the privileges of the process if the image is set-uid or set-gid. Overall, this makes the plain check with p_candebug() inadequate, because we cannot own the process lock over fget_remote().

For that, a facility was developed that provides mutual exclusion for execing in the target process vs. the caller, called execblock. Also, helpers to reference the current vmspace for a process were added, to avoid using execblock when only a consistent target address space is required for the action, like reading of the process strings or copying the process memory. Existing places in system that are affected by the race were identified, and the usage of execblock or vmspace referencing interfaces applied as needed.

Then, the man:pddupfd(2) was implemented with the help of fget_remote() and execblock.

Sponsor: The FreeBSD Foundation

Links:
DevSummit Wiki page URL: https://wiki.freebsd.org/DevSummit/202606
Slides URL: https://wiki.freebsd.org/DevSummit/202606?action=AttachFile&do=view&target=Scheduler.pdf

Contact: Olivier Certner <olce@FreeBSD.org>

Ongoing work is happening in the area of schedulers along multiple axes.

We are working on solutions to long-standing shortcomings in the ULE scheduler such as unfairness for non-interactive threads in certain particular circumstances and the very weak effect of nice values. It seems difficult to solve the first in full with ULE’s current design, so in parallel we have been sketching a new design with the following additional aims:

We have also been reviewing the 4BSD and ULE schedulers in detail, leading to some bug fixes, such as:

A presentation was done at BSDCan 2026’s Developer Summit on these matters (see link at the top).

On the hybrid scheduling front, a number of reviews have been created by Koine Yuusuke with code to support Intel Hardware Feedback Interface (HFI) and Thread Director (ITD), and a common infrastructure for capacities and scores was proposed by Minsoo Choo. We will review and shepherd these submissions.

Sponsor: The FreeBSD Foundation

Links:
Blog URL: https://obiw.ac/s0ix/
BSDCan talk on s2idle/S0ix URL: https://youtu.be/RCjPc4X2Edc
Working branch URL: https://github.com/obiwac/freebsd-s0ix/pull/15

Contact: obiwac <obiwac@FreeBSD.org>

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, some of which do not support ACPI S3 sleep, to enter low power states to increase battery life.

Mostly, the status is the same as the previous quarter — work is still ongoing on narrowing down the NVMe resume issues and fixing up the D-state issues.

The generic power management interface has been committed and zzz(8) has been rewritten to make use of it. You are now expected to use the kern.power.supported_stype sysctl to list supported generic sleep types and set the kern.power.suspend sysctl to the sleep type you would like zzz(8) to use.

A bunch of small fixes and improvements were made to the acpi_spmc driver.

Generic USB4 NHI support has also been committed. The only thing left to commit for the USB4 support required for S0i3 entry is the suspend routine itself. The thunderbolt(4) manpage has been updated to be clearer on the fact that this is only intended to support S0i3 entry.

A manpage has been written for amdsmu(4) to better explain how to diagnose S0i3 entry.

Sponsor: The FreeBSD Foundation

Links:
Image saving prototype URL: https://github.com/OlCe2/freebsd-src/tree/oc-hibernate
EFI loader URL: https://github.com/OlCe2/freebsd-src/tree/for_kib-hiber

Contact: Olivier Certner <olce@FreeBSD.org>
Contact: Konstantin Belousov <kib@FreeBSD.org>

Work is ongoing to have FreeBSD support hibernate (suspend-to-disk), without BIOS/firmware assistance to save the current machine state, for amd64 UEFI-booted machines. See also the previous report.

After a pause of almost two months, we fixed some bugs in the image saving prototype, rebased it on recent code, and revised the interface between the kernel and the resume EFI loader, requiring some changes on both sides. This lead to a number of changes in ACPI general suspend/resume code and in-passing fixes. Work is in progress in the EFI loader (stage 1). A sketch of the kernel resume part (stage 2) was devised.

Some more discussion happened about how to save the system image while preserving its consistency, as the dump operation itself modifies kernel memory. The aim is to narrow down which components can interfere with the dump, and how to prevent that interference. In particular, it appears that low-level DMA and IOMMU code could perform memory allocations in certain circumstances, and it is yet unclear if that could happen during a dump. Once determined, we will pursue eliminating these circumstances if possible, else will work on a snapshot-like mechanism. Beyond that aspect, a live snapshot mechanism could be beneficial as it allows to use any kernel facility without restriction to perform the dump, and in particular alleviates the need to have one dump routine per disk driver.

We presented the current status of this work, associated challenges and possible implementation of a snapshot-like mechanism at BSDCan in June, and will do so again at EuroBSDCon in September.

Sponsor: The FreeBSD Foundation

Contact: Olivier Certner <olce@FreeBSD.org>
Contact: ShengYi Hung <aokblast@FreeBSD.org>

Collaborative Processor Performance Control (CPPC) is a standard introduced by ACPI to allow the OS to manage performance and efficiency levels of CPUs thanks to an abstract performance scale in general uncorrelated to, and more fine-grained, than mere frequency levels.

Work is ongoing again after another kickoff during the Halifax Hackathon at the end of June.

In the works are:

A number of preliminary cleanups and fixes were committed at the end of June.

Sponsor: The FreeBSD Foundation

Contact: Christos Margiolis <christos@FreeBSD.org>

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

2024Q1 URL: https://www.freebsd.org/status/report-2024-01-2024-03/#_audio_stack_improvements
2024Q2 URL: https://www.freebsd.org/status/report-2024-04-2024-06/#_audio_stack_improvements
2024Q3 URL: https://www.freebsd.org/status/report-2024-07-2024-09/#_audio_stack_improvements
2024Q4 URL: https://www.freebsd.org/status/report-2024-10-2024-12/#_audio_stack_improvements
2025Q1 URL: https://www.freebsd.org/status/report-2025-01-2025-03/#_audio_stack_improvements
2025Q2 URL: https://www.freebsd.org/status/report-2025-04-2025-06/#_audio_stack_improvements
2025Q3 URL: https://www.freebsd.org/status/report-2025-07-2025-09/#_audio_stack_improvements
2025Q4 URL: https://www.freebsd.org/status/report-2025-10-2025-12/#_audio_stack_improvements
2026Q1 URL: https://www.freebsd.org/status/report-2026-01-2026-03/#_audio_stack_improvements

Important work since last report:

You can also follow the development process on the FreeBSD Foundation’s status-updates repository, where I post weekly reports.

Sponsor: The FreeBSD Foundation

Links:
Support the MediaTek Wireless cards URL: https://github.com/FreeBSDFoundation/proj-laptop/issues/66
Support the Realtek Wireless cards URL: https://github.com/FreeBSDFoundation/proj-laptop/issues/99
LinuxKPI based WiFi and suspend and resume URL: https://github.com/FreeBSDFoundation/proj-laptop/issues/58
Wireless Problem Reports URL: https://bugs.freebsd.org/bugzilla/showdependencytree.cgi?id=277512&hide_resolved=1

Contact: Bjoern A. Zeeb <bz@FreeBSD.org>
Contact: The FreeBSD wireless mailing list <wireless@FreeBSD.org>

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.

Links:
Update to Linux 6.13 DRM drivers URL: https://github.com/freebsd/drm-kmod/pull/469

Contact: Jean-Sébastien Pédron <dumbbell@FreeBSD.org>

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 finished the porting of DRM drivers from Linux 6.12 LTS in time for the release of FreeBSD 15.1-RELEASE. Because this is an LTS version, we will track changes from the Linux 6.12.x patches. Currently, we are at 6.12.81 and work is underway to continue to bump to the latest patch. These drivers are available from the Ports tree and as packages.

As part of the work on 6.12 drivers, several bugs or regressions were fixed for already supported GPUs. Some newer GPUs started to work as well.

We still have several instabilities to fix in both the i915 and the amdgpu drivers.

We also continued to port DRM drivers from following Linux versions: * The update to Linux 6.13 is under review and testing. * The update to Linux 6.14 is ready as well and will be reviewed after the 6.13 update.

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

Sponsor: The FreeBSD Foundation

Links:
Add Support for Geneve (RFC8926) URL: https://reviews.freebsd.org/D54172

Contact: Pouria Mousavizadeh Tehrani <pouria@FreeBSD.org>

Since the last report, I have committed the geneve(4) driver and it is now available on CURRENT.

Contact: Pouria Mousavizadeh Tehrani <pouria@FreeBSD.org>

For the past 6 months, I have worked on refreshing our IPv6 stack and implementing pending RFCs in our stack, and they are now available on CURRENT.

So far, I have added the support for:

Ongoing works:

I want to specially thanks Gleb Smirnoff for his timeless guidance and help on these works.

Contact: Pouria Mousavizadeh Tehrani <pouria@FreeBSD.org>

I have been working on the metric implementation since 2026Q1. Routing metrics are configuration values used by a router to make routing decisions. Router metrics help the routing stack to choose the best route among multiple feasible routes to a destination. The route will go in the direction of the gateway with the lowest metric. Support for metric in our routing stack is implemented and available in CURRENT. Metric support requires numerous updates to both kernel and userland.

These are some highlights that were added:

You can also leverage metric using net/bird for your routing protocols.

Links:
GSoC Project Wiki
FreeBSD Source Fork

Contact: Subhash Murmu <subhashmurmujsr2511@gmail.com>

This project adds native Multiprotocol Label Switching (MPLS) support to the FreeBSD kernel as part of Google Summer of Code 2026, mentored by Bruce Simpson and Alexander Chernikov. MPLS is widely deployed for label-switched forwarding in production networks, but FreeBSD has no MPLS data plane in the base system, so MPLS-capable routing daemons have no kernel forwarding path to program. The work is built bottom-up, from wire-level encapsulation through the control plane, and integrates with the existing FreeBSD network stack rather than sitting beside it.

Phases 1 through 3 are complete and pushed as a five-commit layered history on the mpls branch of the Codeberg fork. Phase 1 adds link-layer encapsulation and netisr(9) dispatch for EtherType 0x8847. Phase 2 ports OpenBSD’s ldpd(8) to FreeBSD, where it now builds and runs. Phase 3 adds the forwarding engine and a per-VNET Label Information Base, with end-to-end LSP transit verified under tcpdump between VNET jails over epair(4).

The series has not yet been submitted to Phabricator. Work continues on kernel route programming for ldpd.

Sponsor: Google Summer of Code 2026

Links:

FreeBSD wiki project page URL: https://wiki.freebsd.org/SummerOfCode2026Projects/BluetoothSupportForHIDDevices
Project GitHub repo URL: https://github.com/majintosh/freebsd-bthid

Contact: Majed Alkhaleefah <majed@FreeBSD.org>

I have been working on two drivers to enable support for HID drivers for Bluetooth devices as part of GSoC 2026.

The primary goal of this project is to register connected Bluetooth HID devices as Newbus devices via two new drivers: bthidbus and bthid. bthidbus acts as the parent bus that manages the creation and attachment of bthid child devices. bthid serves as the transport layer, spawning a hidbus device and routing all received packets to it once they are stripped of their headers. The short-term goal here is to enable support for wireless HID connections. The longer-term goal is to begin setting the foundation that allows others to write drivers for devices that can only connect via Bluetooth.

What has been accomplished:

Current issues and planned changes:

All testing so far has been done with the Nintendo Switch Pro Controller.

Contact: Konstantin Belousov <kib@FreeBSD.org>

Recently there was a stream of articles hyping the Linux driver ntsync which implemented a helper for Wine to accelerate Windows NT synchronization primitives. The substrates to implement semaphores, mutexes, and events from the Win32 land are provided by it. The driver represents each NT object as a file descriptor, which has the set of the ioctls defined that directly map into the Win32 operations.

The project implemented the driver providing the compatible ntsync interface as specified in the Linux 7.0-rc3 document Documentation/userspace-api/ntsync.rst. Both native FreeBSD interface, and the Linux ABI compatibility layers, are written.

To test the driver, a minimal version of the Linux kernel test harness was ported. FreeBSD driver follows the interface details as encoded by the tests, when a discrepancy between Linux documentation and tests was found.

Both the driver and its man page ntsync(4) were written from scratch, without consulting the Linux source code.

Sponsor: The FreeBSD Foundation

Links:
rpi-imager upstream URL: https://github.com/raspberrypi/rpi-imager
FreeBSD Port pull request URL: https://github.com/raspberrypi/rpi-imager/pull/1655
PR 296480 - FreeBSD Ports open review URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=296480

Contact: Jim Chen <jim.chen.1827@gmail.com> Contact: Nimish Jain <njain15@protonmail.com>

The Raspberry Pi Imager is a convenient graphical tool developed by the Raspberry Pi Foundation that allows users to easily configure and flash operating system images to storage cards for the Raspberry Pi Zero and Raspberry Pi 1-5 series single-board computers.

Our goal in porting this app to FreeBSD is to continue lowering barriers to entry. We want users unfamiliar with the command line to easily flash operating systems to their Raspberry Pi.

Currently, the upstream project supports only Linux, MacOS, and Windows. We have created a FreeBSD port that uses native I/O, disk, and network APIs and links against pre-packaged FreeBSD libraries.

The main blocker for this project is currently upstream uncertainty. The maintainers have requested buy-in from FreeBSD developers to help with the long-term maintenance of the FreeBSD-specific code. If you are a committer or a contributor invested in Raspberry Pi tooling on FreeBSD, please let us know or join the discussion on the GitHub pull request!

If this work is accepted upstream, a Makefile for the FreeBSD Ports repository is ready for review as PR 296480 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=296480).

If you’re interested, please do try out a local release by cloning the Ports tree and applying the patch in the PR mentioned above, and let us know if you have any issues!

Sponsor: The FreeBSD Foundation

Contact: Deepan Sai <skdeepan.sai@gmail.com>

Links:
Wiki URL: https://wiki.freebsd.org/arm/Bananapi

Contact: Martin Filla <freebsd@sysctl.cz>

Contributors are welcome. If you are interested in helping with this project, testing the current implementation, or contributing code, please contact me.

Links:
Framework Laptop page on FreeBSD Wiki URL: https://wiki.freebsd.org/Laptops/Framework_Laptop/
Guide on installing and using FreeBSD on Framework systems URL: https://github.com/FrameworkComputer/freebsd-on-framework
Framework system management tools URL: https://github.com/FrameworkComputer/framework-system
Tracking ticket: Framework Laptop: Feature support, bugs and improvements URL: https://bugs.freebsd.org/262152

Contact: Daniel Schaefer <dhs@frame.work>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>
Contact: Sheng-Yi Hong <aokblast@FreeBSD.org>

Framework Computer Inc. continues to support the FreeBSD Project in many ways. This includes providing engineering samples and development hardware to the FreeBSD Foundation, helping with hardware testing, and working with FreeBSD developers on compatibility improvements.

The Foundation continues to improve overall laptop support. Framework laptops are among the target platforms of the Laptop Support and Usability Project.

During 2026Q2, Daniel updated the sysutils/framework-system port to version 0.6.2 and later to version 0.6.4. This package provides Framework-specific system and firmware management tools for FreeBSD users.

Framework also hosted a small hackathon at its Taipei office during the quarter. FreeBSD developers tested newly announced hardware, including the Intel Panther Lake-based Framework Laptop 13 Pro and the 10GbE adapter.

Li-Wen is working on FreeBSD support for the 10GbE adapter, which uses a Realtek RTL8159 controller.

Support for Intel Panther Lake systems also progressed through development and testing on Framework hardware, including pre-release systems made available by Framework during the Taipei hackathon. Daniel added PCI IDs for Panther Lake I2C and SMBus controllers, and Sheng-Yi committed the work to FreeBSD. A follow-up correction removed an ID for an SPI flash controller that had been incorrectly identified as an SPI bus controller.

In June, Li-Wen also started testing and debugging the Linux 6.12-based DRM drivers from the graphics/drm-612-kmod port, which was added during the quarter. He investigated display-related problems on Framework systems and suspected that some of them might be the same as, or related to, the external-display hot-plug problem tracked in the Laptop Support and Usability Project. The investigation was still in progress at the end of the quarter and continued into Q3.

Power and performance management continued to improve on both Intel and AMD systems. Framework systems were among the development and test platforms used for this work. Some systems were provided by Framework, while FreeBSD developers also carried out development and testing on their own Framework hardware.

Sheng-Yi disabled Intel HWP package-control mode on hybrid-core CPUs. Without this change, a request from an efficiency core could limit all cores to its performance level and cause a significant loss of performance.

Other HWP and CPPC improvements completed during the quarter include:

Work also progressed on suspend and resume support for the Framework Laptop 12. Devin Teske developed and tested a proposed ACPI fix for a wake-up issue that could cause the system to suspend again immediately after resume. Daniel investigated the laptop’s ACPI and embedded-controller firmware behavior, while Warner Losh and Olivier Certner provided technical review and helped improve the implementation.

Sponsor: The FreeBSD Foundation for Li-Wen and Sheng-Yi’s work
Sponsor: Framework Computer Inc. for Daniel’s work and for hardware and space provided to the project

Links:
drm-kmod fork with partial amdkfd support URL: https://github.com/Yohello1/drm-kmod-rocm/tree/super-special
rocm-systems fork with fixes for FreeBSD URL: github.com/Yohello1/rocm-systems

Contact: Sourojeet Adhikari <siri@racha.ca>

ROCm is the compute platform used by AMD for their GPUs. As of now, FreeBSD does not support ROCm at all, neither at the toolchain level nor at the driver level. I am working to change that and upstream the required changes.

To my knowledge, on FreeBSD there are a few ways to run compute loads (like AI/ML, graphics, etc) on the GPU; those ways, to my knowledge, are Vulkan and OpenGL. Both Vulkan and OpenGL are fairly good for compute workloads, namely in graphics and sometimes machine learning loads too. But sometimes there are tasks which are not well-suited for Vulkan and OpenGL, and are instead done in ROCm/CUDA because ROCm and CUDA give the developer a lot more control over how the task is done. So I am trying to introduce ROCm support to FreeBSD so we can run ROCm code/programs on FreeBSD. There are a few things we need working to get ROCm working. The first is AMD’s LLVM fork, which I have patched, gotten working, and have upstreamed the patches. Next are the ROCm runtimes, which have been patched, and I am currently working on upstreaming the patches. Finally is the amdkfd driver, which I am working on patching, and am upstreaming some of the LinuxKPI-related patches back to the FreeBSD kernel.

As of late, I have upstreamed changes to AMD’s LLVM fork allowing the compilation of their fork on FreeBSD so you can build their ROCm toolchain. Beyond that, I have worked on getting a series of patches into LinuxKPI to slowly bring in amdkfd support.

Sponsor: The FreeBSD Foundation

Contact: Colin Percival <cperciva@FreeBSD.org>

FreeBSD is available on both amd64 (Intel and AMD) and arm64 (Graviton) EC2 instances.

An issue causing the ena(4) driver to drop packets when receiving jumbograms has been fixed. The fix was present in 15.1-RELEASE (June) and will be present in 14.5-RELEASE (September). This fix improved single-TCP-stream network performance on some EC2 instances from 110 Mbps to 9.5 Gbps and also significantly improved multiple-TCP-stream throughput.

An issue causing the ena(4) driver to launch taskqueues on the wrong CPU(s) on NUMA systems has been identified. The fix should be present in 14.5-RELEASE (September) and produces a 2x increase in multiple-TCP-stream throughput on c8gn.48xlarge instances.

Sponsor: Amazon
Sponsor: https://www.patreon.com/cperciva

Links:
Microsoft Azure article on FreeBSD wiki URL: https://wiki.freebsd.org/MicrosoftAzure
Microsoft HyperV article on FreeBSD wiki URL: https://wiki.freebsd.org/HyperV

Contact: Microsoft FreeBSD Integration Services Team <bsdic@microsoft.com>
Contact: freebsd-cloud Mailing List
Contact: The FreeBSD Azure Release Engineering Team <releng-azure@FreeBSD.org>
Contact: Wei Hu <whu@FreeBSD.org>, <weh@microsoft.com>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>

Publishing the 15.1-RELEASE image to Azure Marketplace is in progress. It is expected to become publicly available early in the third quarter.

Li-Wen is investigating the technical details needed to support Azure Trusted Launch.

Wei and Li-Wen, together with other Microsoft engineers, are investigating an issue preventing mana(4) from working correctly on AMD-based Azure VMs. The mana(4) device is present on the latest v7-generation Azure VMs.

Work in progress tasks:

Open tasks:

Sponsor: Microsoft for people in Microsoft, and for resources for the rest
Sponsor: The FreeBSD Foundation for everything else

Links:
The FreeBSD Official Website in Russian URL: https://www.freebsd.org/ru/
FAQ URL: https://docs.freebsd.org/ru/books/faq/
The FreeBSD Russian Documentation Project site URL: https://github.com/freebsd-doc-ru/freebsd-doc/discussions

Contact: Andrey Zakhvatov <andy@FreeBSD.org>
Contact: Vladlen Popolitov <vladlen@FreeBSD.org>

The FreeBSD Russian Documentation Project’s current goal is to provide up-to-date Russian translations of the most important parts of the FreeBSD documentation (FAQ, Handbook, website content). It is essential to support Russian-speaking users with high-quality official technical materials and to increase the adoption of the operating system worldwide. We hope this initiative will gain support within the Russian-speaking FreeBSD community and lead to an increase in translated materials.

During the last quarter:

Plan for the next quarter:

Check the official translation guide if you would like to help.

We would appreciate your assistance with translating the following materials:

Links:
freebsd-dockerbox GitHub URL: https://github.com/leafoliage/freebsd-dockerbox
dockerbox-broker GitHub URL: https://github.com/leafoliage/dockerbox-broker
freebsd-dockerbox-debian GitHub URL: https://github.com/leafoliage/freebsd-dockerbox-debian

Contact: Chun-Cheng Yeh <leafoliage@FreeBSD.org>

Dockerbox is a virtualized Docker daemon. Although the Docker daemon is not natively available on FreeBSD, Dockerbox runs it inside a Debian Bhyve virtual machine to provide access to it. Dockerbox supports common Docker features such as Docker Compose, port publishing, and bind mounts. This project aims to facilitate non-production Docker usage on FreeBSD.

Links:
KDE/FreeBSD initiative URL: https://freebsd.kde.org/
FreeBSD — KDE Community Wiki URL: https://community.kde.org/FreeBSD

Contact: KDE on FreeBSD Mailing List <kde@FreeBSD.org>

The KDE on FreeBSD project packages CMake, Qt, and software from the KDE Community, for the FreeBSD ports tree. The software includes a full desktop environment called KDE Plasma (for both X11 and Wayland) and hundreds of applications that can be used on any FreeBSD machine. The KDE team is part of desktop@, building the software stack to make FreeBSD beautiful and usable as a daily driver graphical desktop workstation.

Links:
GCC Project URL: https://gcc.gnu.org/
GCC 13 release series URL: https://gcc.gnu.org/gcc-13/
GCC 14 release series URL: https://gcc.gnu.org/gcc-14/
GCC 15 release series URL: https://gcc.gnu.org/gcc-15/
GCC 16 release series URL: https://gcc.gnu.org/gcc-16/
GCC 17 release series URL: https://gcc.gnu.org/gcc-17/

Contact: Lorenzo Salvadore <salvadore@FreeBSD.org>

Two new ports have been created: lang/gcc16 and lang/gcc17-devel.

PR 294062 about arm64 build failures has been fixed. More precisely, in 2026Q2 lang/gcc16-devel and lang/gcc17-devel have been fixed, while lang/gcc16 has been fixed in the beginning of 2026Q3 (at the time this report is written the patch still needs to be forwarded to the ports quarterly branch). Unfortunately, the solution is local to the FreeBSD ports tree and cannot be upstreamed directly. Discussion for an upstream solution can be found in the upstream bugzilla. Thanks to all those who have helped, in particular to Mark Millard.

I have not worked personally on the process to get GCC_DEFAULT=15 this quarter, but some work is being done in the associated PRs, so this is getting forward as well. Moreover, minor version updates to lang/gcc13, lang/gcc14 and lang/gcc15 are planned.

As I continue to work on the GCC ports, I realize that I am having less time and less energy to put into them. These ports are important, I prefer not to leave them unmaintained at least until I am able to deal with them, even if slowly. But if there is someone who would like to take them, please stand up and I would be glad to transfer maintainership.

Links:
Project description URL: https://freebsdfoundation.org/project/improving-openjdk-on-freebsd/
Project repository URL: https://github.com/freebsd/openjdk
Upstream BSD port repo URL: https://github.com/openjdk/bsd-port

Contact:
Harald Eilertsen <haraldei@FreeBSD.org>
FreeBSD Java mailing list <freebsd-java@lists.freebsd.org>

The goal of this project is to improve OpenJDK support for FreeBSD/amd64 and FreeBSD/arm64.

Java is an important runtime environment for many high performance, critical enterprise systems. Making sure Java based applications run correctly and efficiently on FreeBSD is important to ensure that FreeBSD will continue to be a viable and attractive platform for enterprises, as well as businesses and organizations of all sizes.

This quarter has been spent mostly on getting the upstreaming process properly going. We submit patches to a separate repository under the OpenJDK org on GitHub, and make sure that each PR is reviewed by at least one upstream reviewer. This way, when we get to the point where we want to merge our port into the upstream mainline, all commits should already be reviewed by someone in the project.

This is a fairly slow process, as we depend on upstream reviewers having time. We also encounter that some of the changes that has been living in our port for a long time is rejected. Then we have to rework them, or if not strictly needed, just throw them out. I feel this is a useful correction, but sometimes causes quite a bit of work.

In this quarter the following issues/milestones were reached:

In addition, these tasks are still ongoing, or waiting for review:

Other notes:

Sponsor: The FreeBSD Foundation

Links:
sysutils/slurm-wlm URL: https://cgit.freebsd.org/ports/tree/sysutils/slurm-wlm/
net/ucx URL: https://cgit.freebsd.org/ports/tree/net/ucx/
sysutils/mpifileutils URL: https://cgit.freebsd.org/ports/tree/sysutils/mpifileutils/
devel/libcircle URL: https://cgit.freebsd.org/ports/tree/devel/libcircle/
devel/lwgrp URL: https://cgit.freebsd.org/ports/tree/devel/lwgrp/
devel/dtcmp URL: https://cgit.freebsd.org/ports/tree/devel/dtcmp/
benchmarks/py-reframe-hpc URL: https://cgit.freebsd.org/ports/tree/benchmarks/py-reframe-hpc/
openucx/ucx#11354: UCS/TYPE portability fixes for non-glibc/Clang environments (merged) URL: https://github.com/openucx/ucx/pull/11354
openucx/ucx#11549: UCS/SYS portability fixes for non-Linux platforms (in review) URL: https://github.com/openucx/ucx/pull/11549
hpc/mpifileutils#664: Portability fixes for FreeBSD/non-Linux builds (in review) URL: https://github.com/hpc/mpifileutils/pull/664
Kavocado Monthly Status Reports – FreeBSD HPC notes URL: https://kavocado.net/reports/

Contact: Generic Rikka <rikka.goering@outlook.de>

This report continues the FreeBSD HPC Ports Modernization initiative. Previous quarters focused on bringing the Slurm + PMIx + PRRTE + UCX stack up to date and filling gaps in the surrounding ecosystem. This quarter’s work centered on three things: keeping the core scheduler and communication libraries current against fast-moving upstream releases, upstreaming the FreeBSD portability fixes accumulated while maintaining these ports so the local patchsets keep shrinking, and adding a new port for MPI-parallel file utilities that are common on large HPC filesystems.

Links:
libvirt: Bhyve driver URL: https://libvirt.org/drvbhyve.html

Contact: Roman Bogorodskiy <novel@FreeBSD.org>