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
pf: Fix fallout from the STATE_LOOKUP macro removal
Commit 8572367b6814 ("pf: remove STATE_LOOKUP") introduced two seemingly
unintentional changes with respect to divert(4)-injected packets (i.e.,
the PACKET_LOOPED case): we no longer return the matching state, and
direct callers of pf_find_state() now treat matches of diverted packets
the same as having no matching state at all.
This seems inadvertent, and breaks certain rulesets which use divert-to.
Fix them, and add a regression test case.
Fixes: 8572367b6814 ("pf: remove STATE_LOOKUP")
Reviewed by: kp
MFC after: 2 weeks
Sponsored by: OPNsense
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D59015
(cherry picked from commit 00a793def743b5be8fcbdd39fc1dfa61534ed66c)
rtnetlink: Allow VF priority reporting in trunk mode
PF-administered priority need not impose an access VLAN. Permit the
existing VLAN PCP attribute in either access or trunk mode, while
keeping VLAN identifier and protocol access only.
Display trunk PCP in ifconfig and document the broader meaning in the
kernel snapshot, libifconfig, and rtnetlink contracts. This changes no
attribute numbers, wire encoding, or structure layout.
Reported by: kib
Sponsored by: BBOX.io
acpi_pci: Honor device proximity for DMA tags
A PCI function with its own _PXM still inherits a DMA tag carrying
the upstream bridge's proximity domain. Resolving an SR-IOV VF's
locality through its PF therefore does not affect the domain used for
DMA allocations.
Create and cache a private child tag when the function, or a VF's
owning PF, has an explicit _PXM. Parent it to the existing PCI or IOMMU
tag so its constraints remain intact, then apply the function's domain
without mutating a shared tag.
pci_get_dma_tag() already performs the IOMMU lookup, so remove the
duplicated lookup in the ACPI subclass while here.
Reviewed by: jhb
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D59063
(cherry picked from commit f1f58bdf7b5fc58e6011c6ac2ae2ba129dc41991)
acpi_pci: Cache PCI proximity domains
A PCI function's _PXM is stable for the lifetime of its device
instance, but CPU and DMA locality queries may evaluate it repeatedly.
SR-IOV amplifies this because every VF resolves locality through the
same PF.
Cache successful mappings and the stable absence of _PXM on the
locality source device, and share that result between CPU and domain
queries. Continue to retry generic evaluation or mapping errors rather
than making a potentially transient failure permanent.
Reviewed by: jhb
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D59207
(cherry picked from commit 5f78d024695b39208a6c92f6a96017bae53cdf2c)
acpi_pci: Preserve CPU locality queries for descendants
bus_generic_get_cpus() preserves the original leaf device while
forwarding a request through the bus hierarchy. Consequently,
acpi_pci_get_cpus() may receive a descendant below a PCI function
rather than one of the PCI bus's direct children.
Only apply the SR-IOV PF-locality mapping to direct PCI children.
Preserve the previous ACPI CPU-locality lookup for descendants so their
unrelated bus ivars are not interpreted as PCI device information.
Reviewed by: jhb
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D59206
(cherry picked from commit dc4f80da18f0dcc557a969b4283a86569266eb5c)
acpi_pci: Inherit PF locality for SR-IOV VFs
SR-IOV VFs are instantiated from their PF and intentionally do not
receive an ACPI handle by matching their runtime BDF. Consequently,
ACPI locality queries for a VF fall back to the upstream bus. This is
usually sufficient, but loses a _PXM supplied specifically for the PF.
Use the PCI core's owning-PF accessor for BUS_GET_DOMAIN and
BUS_GET_CPUS requests made for a VF. This preserves the VF's lack of
an ACPI handle while allowing its CPU and NUMA placement to follow the
PF.
Reviewed by: jhb
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D59062
(cherry picked from commit 1a2a88684a0126be8d7172362d5ec7dbb7a41c81)
acpi_pci: Do not match SR-IOV VFs to ACPI devices
SR-IOV VFs are instantiated dynamically from their PF rather than
enumerated from ACPI. A VF's runtime slot and function can match an
unrelated _ADR below the bridge. acpi_pci_save_handle() stores that
handle in the VF's devinfo before acpi_pci_update_device() runs.
If the handle is already bound to another device_t whose parent is not
acpi0, acpi_pci_update_device() panics under INVARIANTS. Without
INVARIANTS, the VF retains the unrelated handle, so subsequent ACPI
lookups, including NUMA and power-management operations, can act on the
wrong namespace node.
Skip ACPI namespace matching for VFs.
Reviewed by: jhb
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D59061
(cherry picked from commit 8b74806161a188103666387013cdd93fb3f5dc07)
acpi_pci: Honor device proximity for DMA tags
A PCI function with its own _PXM still inherits a DMA tag carrying
the upstream bridge's proximity domain. Resolving an SR-IOV VF's
locality through its PF therefore does not affect the domain used for
DMA allocations.
Create and cache a private child tag when the function, or a VF's
owning PF, has an explicit _PXM. Parent it to the existing PCI or IOMMU
tag so its constraints remain intact, then apply the function's domain
without mutating a shared tag.
pci_get_dma_tag() already performs the IOMMU lookup, so remove the
duplicated lookup in the ACPI subclass while here.
Reviewed by: jhb
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D59063
(cherry picked from commit f1f58bdf7b5fc58e6011c6ac2ae2ba129dc41991)
acpi_pci: Cache PCI proximity domains
A PCI function's _PXM is stable for the lifetime of its device
instance, but CPU and DMA locality queries may evaluate it repeatedly.
SR-IOV amplifies this because every VF resolves locality through the
same PF.
Cache successful mappings and the stable absence of _PXM on the
locality source device, and share that result between CPU and domain
queries. Continue to retry generic evaluation or mapping errors rather
than making a potentially transient failure permanent.
Reviewed by: jhb
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D59207
(cherry picked from commit 5f78d024695b39208a6c92f6a96017bae53cdf2c)
acpi_pci: Preserve CPU locality queries for descendants
bus_generic_get_cpus() preserves the original leaf device while
forwarding a request through the bus hierarchy. Consequently,
acpi_pci_get_cpus() may receive a descendant below a PCI function
rather than one of the PCI bus's direct children.
Only apply the SR-IOV PF-locality mapping to direct PCI children.
Preserve the previous ACPI CPU-locality lookup for descendants so their
unrelated bus ivars are not interpreted as PCI device information.
Reviewed by: jhb
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D59206
(cherry picked from commit dc4f80da18f0dcc557a969b4283a86569266eb5c)
acpi_pci: Inherit PF locality for SR-IOV VFs
SR-IOV VFs are instantiated from their PF and intentionally do not
receive an ACPI handle by matching their runtime BDF. Consequently,
ACPI locality queries for a VF fall back to the upstream bus. This is
usually sufficient, but loses a _PXM supplied specifically for the PF.
Use the PCI core's owning-PF accessor for BUS_GET_DOMAIN and
BUS_GET_CPUS requests made for a VF. This preserves the VF's lack of
an ACPI handle while allowing its CPU and NUMA placement to follow the
PF.
Reviewed by: jhb
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D59062
(cherry picked from commit 1a2a88684a0126be8d7172362d5ec7dbb7a41c81)
acpi_pci: Do not match SR-IOV VFs to ACPI devices
SR-IOV VFs are instantiated dynamically from their PF rather than
enumerated from ACPI. A VF's runtime slot and function can match an
unrelated _ADR below the bridge. acpi_pci_save_handle() stores that
handle in the VF's devinfo before acpi_pci_update_device() runs.
If the handle is already bound to another device_t whose parent is not
acpi0, acpi_pci_update_device() panics under INVARIANTS. Without
INVARIANTS, the VF retains the unrelated handle, so subsequent ACPI
lookups, including NUMA and power-management operations, can act on the
wrong namespace node.
Skip ACPI namespace matching for VFs.
Reviewed by: jhb
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D59061
(cherry picked from commit 8b74806161a188103666387013cdd93fb3f5dc07)
