website: Add 2027 events
Oh yeah, that's right, none of this "two weeks out" update,
we're adding the whole entire 2027, and it's still 2026 :)
Some of these do not have a finalized date and will need attention.
Reviewed by: bcr, hrs
Discussed with: adrian, cperciva
Differential Revision: https://reviews.freebsd.org/D61237
aio_mlock.2: Expand document description
+ The old one renders broken because Xr is not correct/portable in Nd
+ Take this opportunity to explain it better using mlock description
MFC after: 3 days
Reviewed by: glebius
Differential Revision: https://reviews.freebsd.org/D61334
tests/sys/kern/ssl_sendfile: double timeouts for :grow and :truncate
The :grow and :truncate testcases fail semi-regularly in CI with
timeouts. Double the timeout to reduce false positives with the tests.
PR: 300699
MFC after: 1 week
Reviewed by: siva
Differential Revision: https://reviews.freebsd.org/D61444
asmc: include sys/kernel.h
This is needed for the `MODULE*` macros.
This include was accidentally removed in the linked commit.
MFC after: 1 week
Reported by: Ian Freislich <ianfreislich at gmail.com>
Fixes: c714cde179a4 ("asmc: split the sysctl layer into asmcsysctl.c")
iflib: Use a single tx dma map
The need for a separate map for TSO and non-TSO seems to have arisen from
a misunderstanding about the DMA requirements for Intel drivers like
ice/ixl/iavf. Specifically, this Intel hardware has a quirk where no
more than N (=8) segs can be DMA'ed per packet on the wire. This limit
was enforced using a DMA map with a low segment limit for non-TSO and a
driver specific check for TSO. This led to a *lot* of complexity in
iflib (~80 extra lines of code that this change removes) when the
limit can simply be enforced via the existing EFBIG mechanisms.
This change adds a new flag, IFLIB_SPARSE_TX, that drivers for hardware
with this quirk must set. When set, it causes non-TSO sends that
exceed isc_tx_nsegment to be treated as if bus_dmamap_load_mbuf_sg()
had returned EFBIG.
Due to the API/KABI change, I've bumped the FreeBSD version as well.
Note kgalazka suggested the flag, rather than a more awkward
[12 lines not shown]
snmp_hostres(3): strengthen work on the devd(8) socket
Use the SOCK_SEQPACKET version of the socket. This guarantees that
messages read won't be glued together. Use sufficient buffer size to
read any message.
Close socket on any kind of error or a short read.
This also fixes a bug when a SOCK_STREAM socket containing exactly
multiple of 512 bytes would block the daemon in read(2) until some
other devd(8) event. Thank to David for catching and analyzing it.
Reported by: David Pfitzner <dpfitzner at netflix.com>
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D61146
devd: expose maximum record size via sysconf(3)
Use UMA allocation size that holds the buffer. The buffer is actually
slightly smaller. Document the latter so that clients don't need to use
+1 if they later want to NUL-terminate a message.
Reviewed by: mjg, imp
Differential Revision: https://reviews.freebsd.org/D61346
devd: define _PATH_DEVD_SOCKET in <paths.h>
Sweep through consumers and use the define.
Reviewed by: kfv, imp
Differential Revision: https://reviews.freebsd.org/D61344
iflib: simplify TXQ_AVAIL
Simply the TXQ_AVAIL() macro to avoid using
get_inuse(txq->ift_size, txq->ift_cidx, txq->ift_pidx, txq->ift_gen)
and instead define it in terms of txq->ift_in_use.
Note that in_use is equivalent, because it is updated at the same time
as cidx/pidx and gen, and under the same serialization. The advantage
is that its cheaper due to using one read and no branches, and
safer, since unlocked reads get an atomic snapshot of availability,
but an unlocked read of multiple counters can produce inconsistent
results.
Reviewed by: kbowling, kgalazka
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D61279
(cherry picked from commit 44df82b11c535ae50b1e5888a361a2bd15d4182b)
iflib: rate limit deferred tx ring drain
When simple_tx gives up & return ENOBUFS because the tx ring is full,
we were doing a GROUPTASK_ENQUEUE(&txq->ift_task) each time.
On a tx ring that has overflowed and is being hammered on
by a fast UDP sender, this can result in a massive increase in
context switches (I've seen over 30M ctxw/sec due to this, and
the ctxsw codepath taking roughly 50% CPU).
This change removes the GROUPTASK_ENQUEUE() and replaces it
with a call to a callout which drains the tx ring. The callout time is
determined based on the link speed, estimating how long it would take
for a large fraction of of a ring containing full-MTU packets to drain.
This removes the 30M ctxsw / sec in my test case and reduces it
to roughly a doubling of ctxsws.
Reviewed by: kbowling
Sponsored by: Netflix
[3 lines not shown]
tpm: crb: Support the ACPI start method
Some AMD firmware TPMs report StartMethod 2 and had no driver. They never
acknowledge CTRL_REQ, so skip the idle and ready requests.
Do not harvest entropy from these TPMs on AMD: on a Ryzen 7 7735HS each
periodic TPM2_GetRandom froze every CPU, for up to 1.2 s (AMD PA-410).
Reviewed by: kbowling
Approved by: kbowling
Differential Revision: https://ron-dev.freebsd.org/FreeBSD/src/pulls/103
(cherry picked from commit 6af18560a124b84549713a5f2b667a1df0990929)
tpm_crb: Use locality registers only with plain CRB
The locality release wait times out on every command on a Framework 13
(Pluton start method), logging every 10 seconds.
Reported by: emaste, tuexen
Reviewed by: kbowling
Approved by: kbowling
Fixes: bfe4be85a935 ("tpm_crb: wait for idle and locality release after each command")
(cherry picked from commit 1dade7024457ee10df1ccae22e3c454e80f82b76)
tpm_crb: wait for idle and locality release after each command
transmit only requested GO_IDLE and the locality release, so a back-to-back
command could see stale state and fail with EIO.
A post-send idle timeout no longer discards a completed response.
Reviewed by: kbowling
Approved by: kbowling
Differential Revision: https://ron-dev.freebsd.org/FreeBSD/src/pulls/93
(cherry picked from commit bfe4be85a9354b92135e105028f2e1b3e0307ada)
tpm: crb: Dump register state on command failures
Include the command code in notification failures and the command code
and execution timeout in completion failures. Capture CRB control
registers on completion timeouts and Pluton mailbox readiness or
acknowledgement timeouts, before cancellation or cleanup changes them.
Include locality registers when present and mailbox registers for the
Pluton start method. The dump contains transport state without command
payloads or response data.
Tested by: olivier, tuexen
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D61128
(cherry picked from commit 915eb355d8fe8555f7a74c6db95bc3c02610a939)
tpm: crb: Correct the Pluton mailbox handshake
Pluton's REPLY register indicates readiness for a new notification, not
completion of the notification just sent. Wait for REPLY=1 before
ringing the mailbox, then wait for START=0 when a synchronous state
change needs acknowledgement.
Use a separate command notification callback that waits for mailbox
readiness but leaves command completion to the existing CRB_CTRL_START
polling. Bound readiness waits by TPM_TIMEOUT_C, including asynchronous
idle notifications, while retaining the command's execution timeout.
This resolves reported command timeouts on a Framework AMD laptop.
Tested by: olivier, tuexen
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D61128
(cherry picked from commit 4995fd4bf2c61e30363e588c5b90d7fc9145bf5e)
ixgbe: Restore EEE exclusion for X550EM_X KR
X550EM_X KR devices do not support EEE and have no setup_eee operation.
The shared-code update restored the capability removed by d61b6a41dd30,
and the E610 EEE support subsequently added an unchecked call during
attach. Together these changes allow a NULL function pointer call when
attaching a KR device.
Remove the incorrect EEE capability and use the NULL-safe ixgbe_setup_eee()
wrapper when enabling EEE at attach.
Removing the unsupported capability also stops exposing eee_state and the
eee.tx_lpi_count and eee.rx_lpi_count sysctls on X550EM_X_KR devices.
Fixes: f72de14ea132 ("ixgbe: update if_ix and ixgbe api with ix-3.3.38 changes")
Fixes: 13ee84c591f8 ("ix(4): Add EEE support for E610 adapters")
Sponsored by: BBOX.io
(cherry picked from commit 4678f9d8dc1324da6c021dc9d376a4671e72ad97)
ixgbe: Guard E610 Link Default Override access
Reading Link Default Override uses the E610 Admin Command Interface,
whose mutex is initialized only on E610. Calling it on other adapters
can hang attach, as observed on X520.
Skip the read on non-E610 devices, leaving the cached policy invalid so
that the existing link-state guard also skips force-link commands.
Reviewed by: kgalazka
Fixes: 7868958f5c79 ("ix(4): Support Total Port Shutdown on E610")
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D61144
(cherry picked from commit 2c6b01416f80462b393bbe70a38cea017325dea8)
ix(4): Support Total Port Shutdown on E610
Firmware controls the physical link state on E610 adapters, similarly to
X700 and E800 adapters. As a result, running "ifconfig down" does not
disable the physical link unless Total Port Shutdown is enabled.
Read the Link Default Override TLV from NVM to detect when Total
Port Shutdown was enabled for given port in system setup. In that
case, force the link down when the interface is stopped and restore
it during link configuration. Leave link state management unchanged
when the TLV is unavailable or the feature is not enabled.
Co-authored-by: Miłosz Linkiewicz <milosz.linkiewicz at intel.com>
Co-authored-by: Tomasz Lichwala <tomasz.lichwala at intel.com>
Signed-off-by: Krzysztof Galazka <krzysztof.galazka at intel.com>
Tested by: Mateusz Moga <mateusz.moga at intel.com>
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D60643
[2 lines not shown]
