vfs_unmountall.9: Fix an outdated .Xr to boot(9)
boot.9 was moved to kern_reboot.9, but this reference was not changed
appropriately.
Reviewed by: mhorne, kib, emaste
Fixes: 800e74955d4e ("boot(9): update to match reality")
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D58350
net/if.c: Add fib-aware ifa_ifwithaddr()
Add FIB selection logic by introducing ifa_ifwithaddr_fib() to
support FIB-specific lookups. Then have ifa_ifwithaddr() wrap it
with RT_ALL_FIBS.
Also, do the same for ifa_ifwithaddr_check().
Reviewed by: glebius, bnovkov
Differential Revision: https://reviews.freebsd.org/D58305
man: Fix RFC 1918 network prefix lengths
According to RFC 1918, the following IP prefixes are reserved for
private internets:
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
This PR fixes the prefix lengths in references to private networks
("RFC 1918 networks", "the standard private IP address ranges").
The changes are limited to man pages.
Signed-off-by: Yusuke Ichiki <public at yusuke.pub>
Pull Request: https://github.com/freebsd/freebsd-src/pull/2328
(cherry picked from commit 1403ca10189c47ad1de3915eeb030deddc114685)
man: Fix RFC 1918 network prefix lengths
According to RFC 1918, the following IP prefixes are reserved for
private internets:
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
This PR fixes the prefix lengths in references to private networks
("RFC 1918 networks", "the standard private IP address ranges").
The changes are limited to man pages.
Signed-off-by: Yusuke Ichiki <public at yusuke.pub>
Pull Request: https://github.com/freebsd/freebsd-src/pull/2328
(cherry picked from commit 1403ca10189c47ad1de3915eeb030deddc114685)
nda: Tag the command set used for devctl errors
Different command sets have different encoding for op codes, etc. While
one can normally puzzle out which is which, it's better to explicitly
tag the command set used.
Sponsored by: Netflix
uvideo: import quirks infrastructure from OpenBSD
Import the device quirk system from OpenBSD to handle UVC devices
that need special handling. This includes:
- UVIDEO_FLAG_ISIGHT_STREAM_HEADER: non-standard streaming header
- UVIDEO_FLAG_REATTACH: needs reattach after firmware upload
- UVIDEO_FLAG_VENDOR_CLASS: incorrectly reports as vendor class
- UVIDEO_FLAG_NOATTACH: device not supported
- UVIDEO_FLAG_FORMAT_INDEX_IN_BMHINT: format index in bmHint
Add quirks table with known devices and lookup function.
Add iSight stream header decoder for Apple iSight cameras.
Obtained from: OpenBSD
uvideo: increase UVIDEO_MAX_PU and UVIDEO_MAX_CT to 32
Some UVC devices (e.g. Logitech C920) expose more than 8 Processing
Unit descriptors, causing "too many PU descriptors found!" errors.
Increase both limits from 8 to 32 to accommodate such devices.
hwpmc: add regression tests for detaching a live process-mode PMC
Attach a process-mode counting PMC to the current process, start it,
then detach and release it while it is still loaded on the hardware -
the case that previously leaked the PMC's runcount reference and
wedged pmc_wait_for_pmc_idle() at release. A second case does the same
from a multi-threaded process so the sibling threads' references have
to be drained too.
The tests need an allocatable process-mode counting event and skip
where none is available (hwpmc(4) not loaded, or a VM without a vPMU).
Reviewed by: adrian
MFC after: 2 weeks
Assisted-by: Claude Code (Fable 5)
Differential Revision: https://reviews.freebsd.org/D58343
hwpmc: drain a process-mode PMC's runcount when a live target detaches
A process-mode PMC's runcount tracks how many CPUs currently have it
loaded in hardware. It is decremented only by the context-switch-out
and process-exit reclaim paths, both of which the scheduler invokes
only for processes flagged P_HWPMC. Detaching a target that still has
the PMC live in hardware dropped the target and cleared P_HWPMC without
taking the PMC off the hardware or dropping the runcount reference, so
the reference leaked. A subsequent release then spun in
pmc_wait_for_pmc_idle() forever waiting for the runcount to reach zero:
on an INVARIANTS kernel this panics ("waiting too long for pmc to be
free"), otherwise it is an unkillable loop holding the hwpmc lock. Any
process able to allocate a PMC can trigger this by attaching a counting
PMC to itself and detaching it before releasing.
Take the PMC off the hardware and drop the runcount reference as part
of detaching, before P_HWPMC is cleared: reclaim it from the detaching
thread's own CPU directly, and, when the detach removes the PMC's last
target, wait for any references held by the target's other threads to
[6 lines not shown]
hwpmc: add regression tests for counting-PMC counter wraparound
Exercise a process-mode counting PMC whose accumulated count crosses,
or already exceeds, the range of the underlying hardware counter.
Before the previous commit, the first context switch after the
hardware counter wrapped panicked INVARIANTS kernels with "negative
increment" and silently corrupted the accumulated count on other
kernels.
The tests need a hardware counting event backed by a counter narrower
than 64 bits and skip where none is available (hwpmc(4) not loaded,
or a VM without a vPMU).
Reviewed by: adrian
MFC after: 2 weeks
Assisted-by: Claude Code (Fable 5)
Differential Revision: https://reviews.freebsd.org/D58341
hwpmc: handle counter wraparound for process-mode counting PMCs
The accumulated count of a process-mode counting PMC is kept in a
64-bit software counter and seeded into the hardware counter at every
context switch in. Hardware counters are narrower than that - each
PMC class discovers and records its own counter width, e.g. 48 bits
on current x86 (queried from CPUID on Intel, architectural on AMD) -
so once the accumulated count approaches the end of the hardware
counter range, the counter wraps during a time slice and the value
read back at switch out is smaller than the value seeded. The
increment was computed assuming a full 64-bit counter: on INVARIANTS
kernels a long enough counting run panics with "negative increment"
the moment the accumulated count first crosses the hardware counter
range, and on other kernels the totals silently lose a full counter
range per wrap.
Compute the increment modulo the per-class hardware counter width
instead, in both places that accumulate switch-out deltas.
[4 lines not shown]
apei: Fix i386 build over bus read, write function
bus_{read,write}_8 are macro wrappers around the corresponding bus_space
functions in sys/bus.h, so implementing bus_{read,write}_8 won't work.
Implement the underlying bus_space function instead.
Reviewed by: jrtc27, rlibby
Fixes: 9313f6b01485
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58301
sched_ule: Fix selecting lowest priority thread early in corner case
When transferring a thread with near 100% CPU statistics (but not 100%;
up to 57.5/59≈97.46%) to a CPU where the enqueue offset is ahead of at
least 2 from the dequeue one, which requires peculiar conditions to
happen (transfer triggered by a bind request or cpuset change, or during
balancing if a thread or more existed from a brief amount of time on the
origin CPU), the transferred thread can get placed after the dequeue
offset, effectively making it appear as a high priority one unduly,
causing latency increase for other threads.
The change here was missed when changing the enqueue and dequeue offsets
update mechanism to recover pre-256-queue-runqueue ULE anti-starvation
and fairness behavior. That change opened up the possibility that these
two offsets are apart by more than one.
Reviewed by: markj
Discussed with: Minsoo Choo <minsoo at minsoo.io>
Fixes: 6792f3411f6d ("sched_ule: Recover previous nice and anti-starvation behaviors")
[3 lines not shown]
procdesc: report NOTE_PDSIGCHLD for traced and stopped process
on attach of the knote. It is same as for NOTE_EXIT when attaching to
the exiting process.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D58327
acl_from_text.c: Allow negative uid/gid numbers to be handled
getfacl / acl_to_text() incorrectly prints uid/gid numbers as signed integers.
This causes uid / gid numbers larger than 2G (2147483648) to print as
negative numbers.
The libc acl_from_text() function does not handle negative numbers.
This diff adds a backwards compatiblity fix to allow negative numbers...
(cherry picked from commit d7d71341ae7d79886143a9ce427dca0e858eda97)
i386: provide PCPU pc_small_core for amd64 compat
Provide pc_small_core for i386 too to fix an i386 build break from x86
code referring to it. It won't be set.
Reviewed by: aokblast, kib
Fixes: 7b26353a59d6 ("hwpstate_intel: Disable package control on hybrid CPU")
Differential Revision: https://reviews.freebsd.org/D58335
re(4): add hw.re.aspm_disable loader tunable
re(4) has unconditionally disabled ASPM L0s/L1 and CLKREQ at attach
for years; on laptops this costs 200mW+ (requested by adrian@ in the PR).
Make it a tunable following the existing hw.re.* pattern:
* default 1 keeps today's behavior;
* 0 preserves the firmware-configured ASPM state at attach and
skips the watchdog re-assert from the previous revision.
Documented in re.4.
* Verified on RTL8168H (XID 0x541): with hw.re.aspm_disable=0,
attach no longer logs "ASPM disabled" and pciconf -lcb shows
the firmware Link Control state preserved -- including Clock PM,
which the unconditional code previously cleared.
* Default (1) is behaviorally identical to the current driver.
[7 lines not shown]
re(4): harden re_watchdog() recovery and log controller state
Distinguish the two failure classes from the PR in a single log line
(ring indices, ISR/IMR, TXCFG, interrupt mode): lost interrupt vs
genuine DMA stall.
Bail out instead of re-initializing when the controller reads back
all-ones (fallen off the bus; reinit cannot help).
Re-assert the driver's existing ASPM-disabled policy before reinit,
since firmware/power transitions re-arming L0s/L1 is a documented
stall trigger.
Diagnostics-only on the recovered path; no fast-path change.
* Field diagnostics running on an RTL8168H production fleet; the log
format distinguishes lost-doorbell / DMA-stall / dead-controller
without a debug build.
[3 lines not shown]
re(4): recover Tx completions whose MSI was swallowed in re_intr_msi()
A Tx completion that raises a status bit between the ISR ack at the top
of re_intr_msi() and the IMR re-enable at the bottom is never re-signalled:
these controllers do not re-assert MSI for an already-set status bit
(this is why hw.re.msi_disable is a known workaround in the PR).
Re-read ISR before re-enabling; if a Tx bit is pending, ack just that bit,
reap the ring and restart the queue. Rx bits are deliberately left set so
they re-arm the interrupt normally and Rx moderation state is untouched.
Also flush the posted IMR write. Mirrors what the INTx path already
achieves via the loop in re_intr().
* MSI interrupt mode on RTL8168H under load; "missed Tx interrupts"
watchdog recoveries no longer occur.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D58278
PR: kern/166724
re(4): re-arm the Tx doorbell when re_txeof() leaves a non-empty ring
On PCIe parts a TxPoll request can be lost when packets are queued
in quick succession, leaving owned descriptors with no transfer in
progress until the watchdog fires. re_txeof() runs from the interrupt
handlers, re_tick() and re_watchdog(), so re-writing TXSTART whenever
the ring is still non-empty turns a potential 5-second stall into at
most one tick.
One register write on a path that already took an interrupt;
fast path untouched.
* Sustained bidirectional load on RTL8168H; no Tx stalls, no throughput
regression at 941 Mbps line rate.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D58277
PR: kern/166724
re(4): quiesce RTL8168G+ and reset before freeing buffers in re_stop()
The STOPREQ command written by re_stop() is not defined for
RTL8168G and later; issuing it can wedge the MAC.
Replace it on those parts with the vendor-documented sequence:
* settle delay
* bounded poll for Tx queue empty
* clear TE/RE
* then bounded poll of the MCU command register (0xD3) FIFO-empty bits.
Also reset the controller before the Rx/Tx buffer free: a controller that
has not quiesced keeps DMAing stale, still-owned descriptors pointing at
freed mbufs (use-after-free under INVARIANTS, cross-NIC mbuf corruption
reported in the PR).
Adds the RL_MCU_* register definitions.
[11 lines not shown]
aq(4): correct Atlantic 2 register access
Four Atlantic 2 register-access corrections found in bring-up.
B0 aggregate octet counters: the B0 firmware statistics interface reports
only aggregate rx/tx good octets, not the per-cast breakdown A0 and
Atlantic 1 provide, so every octet sysctl read a permanent zero while
frame counters advanced. Populate the aggregate octet fields from the B0
buffer; aq_update_hw_stats() accumulates them directly when the per-cast
octets are absent.
Drop the duplicate attach-time MCP reboot: aq_hw_mpi_create() already
reboots the A2 firmware to read its version and caps, then aq_hw_reset()
immediately rebooted it again -- a full MCP restart plus several
transaction-id-bracketed window reads, adding attach latency and a
duplicate banner. Give aq_hw_reset() a reboot flag and pass reboot=false
for A2 at attach; the load-bearing down/stop reboot (which resyncs A2 RX
DMA across ifconfig down/up) keeps reboot=true.
[14 lines not shown]
aq(4): program the Atlantic 2 multiqueue datapath
Wire up the Atlantic 2 receive datapath: the action-resolver table (ART),
multiqueue RSS, QoS, and interrupt moderation.
RX action-resolver table: Atlantic 2 replaces Atlantic 1's discrete RX
filter registers with an ART -- hardware computes a per-packet
classification tag, then walks {tag, mask, action} rows to drop, assign a
queue, or assign a TC. aq_hw_art_filter_set() installs one row under the
ART semaphore; aq_hw_init_rx_path() enables the resolver, tags L2
unicast/broadcast, installs the unicast/all-multicast and VLAN drop rows,
and assigns every 802.1p priority to TC 0 (mirroring the Atlantic 1
user-priority map, since our RX side is a single 8-ring group in TC 0).
Tag every enabled VLAN filter in the per-filter resolver-tag field -- a
register the BSD ports never write -- because the VLAN drop row matches
resolver tag 0, so without it all tagged receive was dead under VLAN
filtering. Promiscuous mode disables the drop rows rather than toggling
the Atlantic 1 promiscuous bits; all ART callers surface a semaphore
timeout consistently. The Atlantic 1 RX_TCP_RSS_HASH and TPO2
[26 lines not shown]
