tests/fib_lookup: Fix compilation by adding SYSDIR
This module is intended to compile in its own directory.
Therefore, the SYSDIR is not defined by default. See 0433870efefc.
Fixes: 8e985774117d ("kern: Remove needless kern.opts.mk")
dpaa2: Allocate DMA tag per Rx buffer
Previously each channel allocated its own set of buffers using the
channel's DMA tag which causes a DMA lock contention under load.
Even a single saturated 1 Gbps link caused ~50,000 adaptive
mutex spin events (as per lockstat) per second. With the proposed
approach there's no more contention on the channel's DMA mutex and the
adaptive mutex spin events dropped to ~6,000/s.
Stress test where iperf3 pushed as much traffic as possible to the 4
ports revealed that throughput drops from expected 940 Mbps down to
600-800 on each link with the "bounce pages lock" generating ~110,000
adaptive mutex spin events per second, but this is to be addressed
later on.
Tested by: flo_purplekraken.com, gnikl_justmail.de, bofh@
MFC after: 3 weeks
Differential Revision: reviews.freebsd.org/D59463
Event: EuroBSDcon Devsummit 2026
LinuxKPI: Fix DMA_BIDIRECTIONAL and other mappings
In dma_sync_single_for_cpu(), the DMA_BIDIRECTIONAL direction currently
performs BUS_DMASYNC_POSTREAD followed by BUS_DMASYNC_PREREAD. This
patch corrects the mapping to use BUS_DMASYNC_POSTREAD |
BUS_DMASYNC_POSTWRITE.
When ownership of the DMA area is transferred to the CPU, we must assume
the previous device access was bidirectional. Both POST operations are
necessary to ensure the CPU sees a consistent view of memory after
potential device reads and writes. A PREREAD is unnecessary here because
the device will no longer access the memory since ownership has been
transferred to the CPU.
Conversely, for dma_sync_single_for_device(), ownership is being
transferred back to the hardware. The buffer must be prepared for
potential bidirectional access by the device, requiring
BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE.
[9 lines not shown]
usbdevs: add TP-Link Archer T4U ver 3
USB Vendor:Product 0x2357:0x0115
The data was provided by Pavel Timofeev (timp87 gmail com)
and the device will be supported by rtw88 USB (rtw8822bu.c)
in the future.
(cherry picked from commit 95e9c3b1aa9fb2e78295e5053e1e84afad938e31)
LinuxKPI: Correct nents passed to dma_{un,}map_sg_attrs()
According to Linux documentation the nents argument to dma_unmap_sg()
must be the number one passed in, not the number of DMA addresses.
In LinuxKPI this means orig_nents and not nents, so adjust this.
Given nents and orig_nents should always be the same in LinuxKPI,
this should only be a NOP for correctness.
Reviewed by: bz, aokblast (LGTM)
Differential Revision: https://reviews.freebsd.org/D57842
(cherry picked from commit 33574d47d9dea317b9a4bfe543c4f20be6a565ef)
LinuxKPI: implement dma_sync_sg_for_{cpu, device}()
Implement dma_sync_sg_for_{cpu, device}() and
dma_sync_sgtable_for_device().
These functions are useful for my GSoC 2026 project, udmabuf.
Reviewed by: bz
Differential Revision: https://reviews.freebsd.org/D57766
(cherry picked from commit 9dec0cd79c693951fc58d82a99918fc5a02cbcd0)
ath10k: remove some early FreeBSD-specific debugging
The extra DELAY seems to no longer be needed and the dump_stack()
is definitively a problem now. Remove all this.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 523c3992cf9e50dce7948372ef703f0057e22561)
LinuxKPI: 802.11: implement cfg80211_calculate_bitrate()
lkpi_cfg80211_calculate_bitrate_vht() was constantly showing up
in my debug traces as a TODO with rtw89 so I went ahead and implemented
the HT and VHT versions. Realtek seems to limit amsdu sizes based
on the value and ask for it whether needed or not.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 654cffe59dd6c8818241bf44eff333af28e10168)
LinuxKPI: 802.11: add != NULL check in ieee80211_tx_status_ext()
There seems to be another possible race with net80211 state machine
changing the bss from under us (another lvif_bss_synched case).
Just do the != NULL check to avoid a NULL pointer deref in
ieee80211_ratectl_rate().
(bz extended the original comment and wrote the commit message).
Sponosred by: The FreeBSD Foundation (commit)
PR: 297184
(cherry picked from commit 0211e64ce1e5ba208f4b96453ce6740a49689b91)
LinuxKPI: 802.11: assert wiphy lock for lkpi_bss_info_change() and MO
Finish reviewing all callers for lkpi_80211_mo_link_info_changed() and
lkpi_80211_mo_bss_info_changed(), which are called from
lkpi_bss_info_change() only. Add the lockdep_assert_wiphy() to
lkpi_bss_info_change() and make sure all callers are holding the
wiphy lock.
PR: 297228
Sponsored by: The FreeBSD Foundation
(cherry picked from commit d1057074b277443e11b04e8513acdf43fd133123)
LinuxKPI: 802.11: deal with wdev list, and misc
Fill in more (lvif) wdev details and add it to the list under the wiphy
struct so that iterators at least work and find the (one) device.
This is needed for the upcoming espwl(4) driver.
misc: add WPI-SMS4 to the list of cipher suits (we won't support it but
at least print the name).
(cherry picked from commit 3e42109d846766248b7d0d0b077543ffc1a9db22)
LinuxKPI: 802.11: add more defines, structures, ...
Add more defines, structures, sort struct field types, add inline
functions (partially implemented) all needed for the upcoming
espwl(4) wireless driver.
(cherry picked from commit 9b13e6ce5b099af0958a824fa37c70538a8b6d2a)
nd6: Fix the array size in union nd_opts
ND_OPT_ROUTE_INFO is 24, so an access of that index is technically out
of bounds, though note that the per-option struct has an entry for this
option. Fix the array size to appease -fsanitize=array-bounds.
Reviewed by: pouria, glebius
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59392
dtrace/arm64: de-pessimize dtrace_copy
When DTrace catches a data abort exception it resumes execution on the
next instruction. If a probe executes copyinto from unmapped memory,
then dtrace_copy keeps faulting on successive bytes until the loop
counter is exhausted. Detect the situation by witnessing the absence
of zero-extension from an aborted unprivileged load.
Reviewed by: markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D59341
