e1000: Retry transient MDIC failures on modern PCH
Some Meteor Lake and newer systems sporadically fail an MDIC PHY
transaction while the MAC and PHY clocks synchronize. Retry twice
before reporting the transaction failure.
Disable retries around PHY interface transitions where an MDI error
is expected. Preserve and restore the configured retry count on every
exit from those flows.
This follows DPDK commit bdca22d62ff0, extended to the PTP and NVP PCH
types.
MFC after: 2 weeks
e1000: fix semaphore timeout value
DPDK commit message
net/e1000/base: fix semaphore timeout value
According to datasheet, software ownership of SWSM.SWESMBI bit should
not exceed 100ms. Current implementation caused incorrect timeout
counter values, where each iteration equals 50us delay. Because of that
driver was allowed to wait for semaphore even for 1.5s. This might
trigger DPC timeout.
This implementation hardcodes value to 2000, which multiplied by 50us,
gives 100ms of possible wait time.
Fixes: af75078fece3 ("first public release")
Cc: stable at dpdk.org
Signed-off-by: Pawel Malinowski <pawel.malinowski at intel.com>
[5 lines not shown]
e1000: Separate hardware semaphore policies by family
The shared semaphore helper accesses both the 82571 retry counter and
the I210 one-time-clear flag. Those fields occupy overlapping members
of the device-specific union. On 82571, incrementing the counter thus
enables the I210 recovery and clears SMBI after the first timeout.
Give 82571, generic 80003/82575, and I210/I211 users distinct acquire
paths. Preserve the legacy peer-driver policy on 82571 and one-time
recovery on I210.
The separation follows the Intel e1000 base code in DPDK.
MFC after: 2 weeks
e1000: Accept uninitialized Tiger Lake NVM checksums
Some transitional Tiger Lake systems shipped with an uninitialized
checksum word. Accept that state while continuing to validate newer
read-only NVM images.
MFC after: 2 weeks
e1000: improve NVM checksum handling
DPDK commit message
net/e1000/base: improve NVM checksum handling
When reading NVM checksum, we may encounter the following scenarios:
- Checksum may be invalid, and can be updated
- Checksum may be invalid but cannot be updated because NVM is read-only
For the latter case, we should just ignore invalid checksum and not
attempt to update it.
Signed-off-by: Sasha Neftin <sasha.neftin at intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov at intel.com>
Acked-by: Bruce Richardson <bruce.richardson at intel.com>
Obtained from: DPDK (5241c17f0d)
MFC after: 2 weeks
e1000: fix NVM data type in bit shift
DPDK commit message
net/e1000/base: fix NVM data type in bit shift
There is a static analysis warning due to wrong data types being used
for NVM read data shifts. Fix it via explicit type cast.
Fixes: 38db3f7f50bd ("e1000: update base driver")
Cc: stable at dpdk.org
Signed-off-by: Przemyslaw Ciesielski <przemyslaw.ciesielski at intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov at intel.com>
Acked-by: Bruce Richardson <bruce.richardson at intel.com>
Obtained from: DPDK (b932270c66)
MFC after: 2 weeks
e1000: fix possible variable overflow
DPDK commit message
net/e1000/base: fix possible variable overflow
Bits can be lost as temporary math is done on signed variables and the
result is assigned to an unsigned variable. Cast to u32 to force the
compiler to do operations on unsigned temporary variables.
Fixes: af75078fece3 ("first public release")
Cc: stable at dpdk.org
Signed-off-by: Lukasz Czapnik <lukasz.czapnik at intel.com>
Signed-off-by: Ciara Loftus <ciara.loftus at intel.com>
Acked-by: Bruce Richardson <bruce.richardson at intel.com>
Obtained from: DPDK (214cb0d7f1)
MFC after: 2 weeks
e1000: fix iterator type
DPDK commit message
net/e1000/base: fix iterator type
Fix static analysis warning about comparison between types of
incompatible width, which might lead to an infinite loop due to
overflow.
Fixes: af75078fece3 ("first public release")
Cc: stable at dpdk.org
Signed-off-by: Amir Avivi <amir.avivi at intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov at intel.com>
Acked-by: Bruce Richardson <bruce.richardson at intel.com>
Obtained from: DPDK (3d36053991)
MFC after: 2 weeks
cuse: Fix server reference leak in cuse_client_open()
If the server is closing (or the device node is going away), or if
devfs_set_cdevpriv() fails, cuse_client_open() returns with the server
reference taken at the top of the function still held and the newly
allocated client still linked on pcs->hcli. Since cuse_client_free()
has not been registered as the cdevpriv destructor at that point,
nothing ever undoes this work: every open() that races the is_closing
window permanently leaks one server reference and one cuse_client.
A leaked reference is fatal on server exit: cuse_server_free()
busy-waits in an uninterruptible pause("W", hz) loop until pcs->refs
drops to 1, which now never happens, so the exiting server process
(e.g. virtual_oss(8)) is left wedged in state "D", immune to SIGKILL,
cuse.ko is pinned (kldunload hangs too), and only a reboot recovers.
Before 634e578ac7b0 the is_closing error path dropped the reference by
calling devfs_clear_cdevpriv(), which ran the cuse_client_free()
destructor. That commit moved devfs_set_cdevpriv() after the
[16 lines not shown]
snd_uaudio: Don't let an idle stream reprogram a shared UAC2 clock
Some UAC2 devices expose a single Clock Source entity that is shared
between their playback and capture interfaces (it appears in both the
output and input clock bitmaps). On such a device uaudio(4) programs
the sample rate for both directions when a stream starts. If playback
runs at a 44.1 kHz-family rate while the idle capture channel is left
at its 48 kHz-family default, the capture
SET_CUR(UA20_CS_SAM_FREQ_CONTROL) is issued after the playback one and
overwrites the rate on the shared clock. The device then runs at
~48 kHz while the playback stream carries 44.1 kHz data. Consuming
samples faster than they arrive, the device repeatedly runs out of
data, loses sync with the playback stream, and re-locks onto it
(audible dropouts, front-panel play/idle flicker). The 48 kHz family
is unaffected because both directions then agree on the rate.
Fix it in three parts:
- Add a shared-clock guard: before issuing SET_CUR to a clock id, if
[30 lines not shown]
sound: Propagate error value from dsp_make_dev()
It is better to propagate it to pcm_register(), and later to the device
drivers, than to simply ignore it and return ENXIO.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
(cherry picked from commit a46c92aad16bf6c9d6c3967c8af3e8b3bdb59cda)
sound: Stop using legacy u_int types
No functional change intended.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
(cherry picked from commit 95439b803fce86958e1db1927a8405bf939edda4)
sound: Scale PCM secondary buffers by byte rate
The fixed 128 KiB secondary buffer cap dates from stereo-sized streams.
High channel-count or high sample-width OSS streams can consume most of
that budget in one graph quantum, leaving too little room for capture
catch-up or playback headroom.
Keep 128 KiB as the low-rate floor, but derive the effective soft-ring
cap from the channel byte rate, clamped to 4 MiB. Use that per-channel
cap when resizing the soft buffer and when clamping
SNDCTL_DSP_SETFRAGMENT requests.
Also clamp SNDCTL_DSP_LOW_WATER to the current soft-buffer size so an
impossible readiness threshold cannot make poll/select wait forever.
MFC after: 3 weeks
Reviewed by: christos
Differential Revision: https://reviews.freebsd.org/D58064
(cherry picked from commit 967e86d1ef2ac8711c0ae7be353a9c08186f4e6f)
linuxulator: map IFF_LOWER_UP through NETLINK_ROUTE for Linux apps
rtnl_if_flags_to_linux() translated the usual IFF_* bits but dropped
FreeBSD's IFF_LOWER_UP (IFF_NETLINK_1). Chromium's AddressTrackerLinux
only treats a link as online when ifi_flags has UP|LOWER_UP|RUNNING; with
LOWER_UP missing, online_links stays empty, ConnectionType is
CONNECTION_NONE, and navigator.onLine is false even though TCP/HTTPS
work. Linux Chromium under the Linuxulator (e.g. www/linux-brave) then
shows a spurious Offline UI; sites that ignore navigator.onLine do not.
Native www/chromium is on a different notifier path.
Map IFF_LOWER_UP to Linux's IFF_LOWER_UP (1<<16) and define
LINUX_IFF_LOWER_UP alongside the existing LINUX_IFF_* constants.
PR: 297424
Reviewed by: pouria, adrian (previous revision)
Differential Revision: https://reviews.freebsd.org/D58774
in_mcast: Fix uninitialized variable usage in inm_merge()
When the first loop in inm_merge() hits an error, generally because it
hit some limit on the number of source filters for a multicast group,
inm_merge() tries to atomically roll back changes to the group source
filter list.
To roll back, it iterates over the global source filter list for the
multicast group, starting at the last entry that we updated ("nims").
But, if we have not yet updated any entries, this variable is
uninitialized. Initialize it to NULL, so that RB_FOREACH_REVERSE_FROM
doesn't visit any source filters in this case.
All of the above applies to the v6 case.
Reported by: Daniel Birtwhistle
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
git-mfc: Make --pending work with releng branches
There is no timeout period for merging from stable to releng branches,
so we should ignore "MFC after" tags.
While here, lift some uses of re.compile() out of loops.
Reported by: des
hwpmc: fix false callchain assertion on the PMC_UR ring
pmc_capture_user_callchain() asserts that TDP_CALLCHAIN is set on the
current thread, but PMC_UR samples never set that flag -- only PMC_HR
and PMC_SR do. That makes the assertion always fail for PMC_UR,
panicking INVARIANTS kernels as soon as pmcstat -U is used.
Skip the assertion for PMC_UR. No functional change on kernels built
without INVARIANTS.
Signed-off-by: Andre Silva <andasilv at amd.com>
Reviewed by: mhorne
MFC after: 1 week
Sponsored by: AMD
Differential Revision: https://reviews.freebsd.org/D58572
hwpmc: fix false runcount assertion in user callchain capture
pmc_capture_user_callchain() checks a PMC's runcount before walking
the user stack, but reads it without holding the spinlock that
protects it. hardclock() can run on the same CPU during the capture
and drop the runcount to zero in between, tripping the assertion and
panicking INVARIANTS kernels under load.
Move the check inside the existing spinlock, right where the code
already confirms the sample is still valid. No functional change on
kernels built without INVARIANTS.
Signed-off-by: Andre Silva <andasilv at amd.com>
Reviewed by: mhorne
MFC after: 1 week
Sponsored by: AMD
Differential Revision: https://reviews.freebsd.org/D58571
e1000: Disable autonomous PCH power gating after reset
Panther Point changed the reset value of CTRL_EXT.DPG_EN to enable
autonomous power gating. Clear it after hardware reset on Panther Point
and Nova Point controllers to prevent unexpected Tx/Rx hangs, packet
loss, or corruption.
MFC after: 1 week
ice(4): Add support for E835 CNSA 2.0 adapters
Added support for E835 adapters with post-quantum cryptographic (PQC)
algorithms in firmware/software signage and in SPDM attestation.
Signed-off-by: Pawel Sobczyk <pawel.sobczyk at intel.com>
Reviewed by: Miłosz Linkiewicz <milosz.linkiewicz at intel.com>
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D57868
SYSINIT: add SI_SUB_NUMA
This allows to parse ACPI tables and initialize VM domains before
SI_SUB_VM w/o a hack.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D58713
SYSINIT: add SI_SUB_FIRST
This allows to initialize mp_maxid, mp_ncpus and register APICs at the
most early stage, guaranteeing that those values will already be available
at SI_SUB_TUNABLES.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D58712
SYSINIT: add explicit SI_ORDER_LAST
Working on cleansing use of (SI_SUB_FOO + 1) construct through the kernel
I found a repeating pattern. Often a developer adds a module that depends
on certain subsystem to be fully instantiated and they want to put their
module SYSINIT right at the end of the SI_SUB_FOO. Such module usually
expects that nothing else within this subsystem shall depend on the
module.
The problem with SI_ORDER_ANY which practically was "the last" until this
change is that it is used very widely and people treat it literally as
"any", well, because this is what the name says. This lead to many parts
that could have dependencies later to be added as SI_ORDER_ANY.
So, our developer with the new subsystem that depends on SI_SUB_FOO has
three options:
1) Use SI_ORDER_ANY, but grep around ther kernel for other SI_SUB_FOO
entries to make sure that no dependencies are set to SI_ORDER_ANY. And in
[16 lines not shown]
bhyve: namescope virtio_msix to virtio.msix
The bhyve_config(5) variable `virtio_msix` is namescoped to
`virtio.msix`. Configurations that have the old variable will
automatically be mapped to the new one, with a warning message printed
out.
Relnotes: yes
Reviewed by: ziaee, markj
Differential Revision: https://reviews.freebsd.org/D58390
