When in netmap (emulated) mode, wireguard interfaces prepend or strip a
dummy ethernet header when interfacing with netmap. The netmap
application thus sees unencrypted, de-encapsulated frames with a fixed
header.
In this mode, netmap hooks the if_input and if_transmit routines of the
ifnet. Packets from the host TX ring are handled by wg_if_input(),
which simply hands them to the netisr layer; packets which would
otherwise be tunneled are intercepted in wg_output() and placed in the
host RX ring.
The "physical" TX ring is processed by wg_transmit(), which behaves
identically to wg_output() when netmap is not enabled, and packets
appear in the "physical" RX ring by hooking wg_deliver_in().
Reviewed by: vmaffione
MFC after: 1 month
Sponsored by: Klara, Inc.
Sponsored by: Zenarmor
Differential Revision: https://reviews.freebsd.org/D43460
When executing `ifconfig -v` this will lead to stalls for a second per interface due to the timeout being set to a static 10 without a module placed, this patch makes sure this is only allowed once per insertion.
In (unknown) situations it seems the i2c bus can have trouble,
while nothing about the current link state has changed, the driver
would react by going into a link down state, and start busylooping
on up to 4 cores. Even if there was a valid link, such spinning
on a cpu by a kernel thread would wreak havoc to existing and
new connections.
This patch does the following:
1. If such a bus failure occurs, we keep the last known link state.
2. Prevent busy looping by implementing the lockmgr() facility to
be able to sleep while the i2c code waits on the i2c ISR. We cap
this with a timeout.
3. Pin the admin queues to the last CPU in the system, to prevent
other scenarios where busy looping might occur from landing on CPU
0, which especially seems to cause a lot of issues.
Given the design constraints both in hardware and in software,
the lockmgr() seems to be the only viable option, even though
FreeBSD explicitly forbids sleeping in callout context, but
fails to explain why this is or offer alternatives.
axgbe: revert allocating admin queues to last CPU
The issue was resolved in 52454a1e5b.
Scheduled threads such as CARP are now no longer pinned to CPU 0, making sure
they always get their time slice even if CPUs are blocked.
Since the I/O expander chip does not do a reset when soft power
cycling, the driver will first turn off all LEDs when initializing,
although no specific routine seems to be called when powering down.
This means that the LEDs will stay on until the driver has booted up,
after which the driver will be in a consistent state.
Initially, RSF (Receive Queue Store and Forward) was disabled for
unknown reasons, but the cut-through mode that's enabled as a result
seems to send 0 length packets up to the DMA when the RX queue is
full.
Since the iflib interface needs axgbe_pci_init() and its phy starting capabilities, no data was passed in its absence.
With the NULL check of the axgbe_miibus we also resort back to an MDIO read as a module might be capable of both
clause 22 and clause 45 methods of communication.
with the move of phy_stop() to if_detach() in d50d4e8cd4, it's better to prevent reconfiguring the phy should the pci_init() callout trigger more than once.
Within the code path of autonegotiation for gigabit SFP modules was a bug, causing
a report of LINK_ERR for cases where an external SFP PHY was present. Fixing this issue
did not resolve to a link however, as it turned out that while autonegotiation interrupts
were happening, it's resulting status cannot be correctly determined in all cases. In these
specific cases we have no other option than to assume a module has negotiated to 1Gbit/s.
PHY-specific configuration has been delegated to the miibus driver, if an external PHY is present.
It's possible that the i2c bus does not recognize a PHY on the first pass, so in all cases we
retry up to a maximum of 5 times during each link poll pass to ensure we didn't miss the presence
of an external PHY.
This commit also addresses link issues on both 100 mbit and 1Gb fiber modules. Not all of these modules
have the correct data set according to SFF-8472, as such we first check for gigabit compliance and
the associated baudrate, otherwise we resort back to determining what type of fiber module is plugged
in by checking the baudrate, cable length and wavelength and setting the MAC speed accordingly.
It is possible for a machine to boot into a state in which the configuration register,
responsible for controlling wether an I/O signal is considered an input or output,
contains randomized values. It was assumed this was programmed by the BIOS.
If I/O is reversed, it's possible for the driver to think an SFPP module has been inserted
when there is none, leading to unrecoverable I2C errors.
The configuration register should contain a state which is determined and provided by the BIOS,
hence no hard-coded values are programmed here.
The current check is never false and if nvlist_unpack() fails, we might
panic later down the road.
PR: 266144
Sponsored by: The FreeBSD Foundation
MFC after: 1 day
Reviewed by: dev_submerge.ch, emaste
Differential Revision: https://reviews.freebsd.org/D45237
(cherry picked from commit 64f4e2db6d19d8ab520903a197fcaa8cc7ab9f9a)
(cherry picked from commit 45feaa73c6)
Approved by: re (cperciva)
SNDSTIOC_ADD_USER_DEVS* expects a user-supplied sndstioc_nv_arg->nbytes,
however we currently do not check whether this size is actually valid,
which results in a panic when SNDSTIOC_ADD_USER_DEVS* is called with an
invalid size. sndstat_add_user_devs() calls
sndstat_unpack_user_nvlbuf(), which then calls malloc() with that size.
PR: 266142
Sponsored by: The FreeBSD Foundation
MFC after: 1 day
Reviewed by: brooks
Differential Revision: https://reviews.freebsd.org/D45236
(cherry picked from commit 074d337ad618f9cc2a1d5ab18b484928e57bd72b)
(cherry picked from commit 5830a00c2c)
Approved by: re (cperciva)
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D45105
(cherry picked from commit 278953360e0e6187c3f7c688cb49254df1567f0b)
(cherry picked from commit 7814ed2bd3)
Approved by: re (cperciva)
According to the OSS manual, oss_sysinfo->numcards holds the number of
detected audio devices in the system, while the current ncards variable,
whose value is assigned to oss_sysinfo->numcards, holds the number of
currently registered devices only.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: dev_submerge.ch, emaste
Differential Revision: https://reviews.freebsd.org/D45136
(cherry picked from commit 59d98edae3e1a6fffd292e4393c49862d624f25f)
(cherry picked from commit 2b36982887)
Approved by: re (cperciva)
nmix is used to compare against oss_mixerinfo->dev, which is a
user-supplied value to select the mixer device (if not -1, in which case
we'll select the default one) we want to fetch the information of. It is
also used to set oss_mixerinfo->dev in case it is -1.
However, nmix is at best redundant, since we have the loop counter
already (i), and confusing at worst.
For example, suppose a system with 3 mixer devices. We call
SNDCTL_MIXERINFO with oss_mixerinfo->dev=1, meaning we want to get
information for /dev/mixer1. Suppose /dev/mixer0 detaches while inside
the loop, so we'll hit the loop's "continue" case, and nmix won't get
incremented (i.e will stay 0 for now). At this point nmix counts 1
device less, so when it reaches 1, we'll be fetching /dev/mixer2's
information instead of /dev/mixer1's.
This is also true in case the mixer device disappears prior to the call
to mixer_oss_mixerinfo().
Simply remove nmix and use the loop counter to both set
oss_mixerinfo->dev and check against it in case a non -1 value is
supplied.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D45135
(cherry picked from commit 2f31a5eb75f1e47b5c49f574e8ce48d2c863e9d3)
(cherry picked from commit 8b4e2ba31d)
Approved by: re (cperciva)
irdma_get_vlan_ipv4() calls ip_ifp_find() even if INET isn't defined, in
which case this function isn't available.
Stub this out for the non-INET case to return an error (0xffff) instead.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1156
(cherry picked from commit 0478a0356272ab3907af9d97711f0bb8b14bf38b)
(cherry picked from commit 7aba922879)
Approved-by: re (cperciva)
Currently we are force-destroying all channels unconditionally in
pcm_killchan(). However, since asynchronous audio device detach is
possible as of 44e128fe9d92, if we do not check whether the channel is
sleeping or not and forcefully kill it, we will get a panic from
cv_timedwait_sig() (called from chn_sleep()), because it will try to use
a freed lock/cv.
Modify pcm_killchan() (renamed to pcm_killchans() since that's a more
appropriate name now) to loop through the channel list and destroy only
the channels that are awake, otherwise wake up the sleeping thread and
try again. This loop is repeated until all channels are awakened and
destroyed.
To reduce code duplication, implement chn_shutdown() which wakes up the
channel and sets CHN_F_DEAD, and use it in pcm_unregister() and
pcm_killchans().
Reported by: KASAN
Fixes: 44e128fe9d92 ("sound: Implement asynchronous device detach")
Sponsored by: The FreeBSD Foundation
MFC after: 1 day
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D44923
(cherry picked from commit 03614fcba25b9de99e69819bc4690f66a3d24438)
Make sure that the softc isn't freed in between the checks.
Sponsored by: The FreeBSD Foundation
MFC after; 1 day
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D44991
(cherry picked from commit b18b990d8e7b15d25243d85ea22374dfdde8a18b)
If we only have a single soundcard attached and we detach it right
before entering [dsp|mixer]_clone(), there is a chance pcm_unregister()
will have returned already, meaning it will have set snd_unit to -1, and
thus devclass_get_softc() will return NULL here.
While here, 1) move the calls to dsp_destroy_dev() and mixer_uninit()
below the point where we unset SD_F_REGISTERED, and 2) follow what
mixer_clone() does and make sure we don't use a NULL d->dsp_dev in
dsp_clone().
Reported by: KASAN
Sponsored by: The FreeBSD Foundation
MFC after: 1 day
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D44924
(cherry picked from commit 074d6fbebc160222cde6b726adcc7350881d7824)
It is marked as obsolete and there are no consumers of it anymore.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: markj, emaste
Differential Revision: https://reviews.freebsd.org/D44853
(cherry picked from commit 17969e696325273e250a1dc73f43de76c0836aae)
In ahc_init(), qoutfifo is already assigned to effectively the same
value a couple lines up, except in the first assignment it uses the
proper definition; keep the more descriptive assignment.
ahc_targetcmd_offset() gets the offset wrong entirely; as per the
area of ahc_init() this diff also touches, targetcmds is laid out first
in the shared map and it's followed by the qoutfifo. As a result, we'd
generally be getting negative offsets here. We can't actually do a
partial sync anyways, so there was no consequence to getting this wrong.
Reviewed by: imp, mav
(cherry picked from commit b5e0cc2fa44f52f16fc0b9c3f1709bc0f43fe2d0)
One of the comments in ahc_execute_scb() notes that the CAM direction is
actually w.r.t. the initiator. As a consequence, all of our sync ops
end up being wrong because the direction is flipped from that of the
transfer. Fix it to do proper invalidation and avoid spewing random
garbage out on the SCSI bus.
Reported and tested by: HP van Braam <hp@tmm.cx>
Reviewed by: imp, mav
(cherry picked from commit 9dcf39575efb2ff32f955d9e04e04af28d45d798)
This is trivial fix of hdacc_detach to avoid duplicated free on snd_hda
unloading.
The first try of detaching (kldunload) may results into "device busy" error,
but codec->fgs is freed by detach. Second try attempts to free codec->fgs again
and system panicks.
Here is example:
pcm0: unregister: channel pcm0:virtual:dsp0.vp0 busy (pid 3428)
pulseaudio[3428] [oss] module-oss.c: DSP shutdown.
pcm0: detached
hdaa0: detached
panic: Duplicate free of 0xfffff80412ee7d20 from zone 0xfffffe006bc0ba00
(malloc-32) slab 0xfffff80412ee7fc8(105)
cpuid = 6
time = 1712999565
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0202f859e0
vpanic() at vpanic+0x135/frame 0xfffffe0202f85b10
panic() at panic+0x43/frame 0xfffffe0202f85b70
uma_dbg_free() at uma_dbg_free+0x105/frame 0xfffffe0202f85b90
uma_zfree_arg() at uma_zfree_arg+0x95/frame 0xfffffe0202f85be0
free() at free+0xa1/frame 0xfffffe0202f85c20
hdacc_detach() at hdacc_detach+0x2f/frame 0xfffffe0202f85c40
device_detach() at device_detach+0x197/frame 0xfffffe0202f85c80
devclass_driver_deleted() at devclass_driver_deleted+0x66/frame 0xfffffe0202f85c
devclass_delete_driver() at devclass_delete_driver+0x81/frame 0xfffffe0202f85d00
driver_module_handler() at driver_module_handler+0xff/frame 0xfffffe0202f85d50
module_unload() at module_unload+0x32/frame 0xfffffe0202f85d70
linker_file_unload() at linker_file_unload+0x1eb/frame 0xfffffe0202f85db0
kern_kldunload() at kern_kldunload+0x18e/frame 0xfffffe0202f85e00
amd64_syscall() at amd64_syscall+0x153/frame 0xfffffe0202f85f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0202f85f30
MFC after: 3 days
Reviewed by: markj, christos
Differential Revision: https://reviews.freebsd.org/D44778
Sponsored by: Postgres Professional
(cherry picked from commit bed0b2146faa2e9a445d9f9196c7b46f50034631)
This is based off the Linux file sound/hda/intel-dsp-config.c.
Tested on: Lenovo Thinkbook 16 G6+ IMH
MFC after: 3 days
Reviewed by: markj, christos
Differential Revision: https://reviews.freebsd.org/D44777
Sponsored by: Postgres Professional
(cherry picked from commit 1dd1a696c58fb275aa0e01666d57861eeb51878d)
On laptops with builtin batteries, disconnecting the battery may show up
as a battery without any capacity information. (The theory is that one
is disconnecting the cells but the electronics identifying the battery
are still connected.) As a result, the loop over all batteries in
acpi_battery_get_battinfo results in total_lfcap == 0.
So, just check that total_lfcap is non-zero to avoid a division by zero
(triggerable by sysctl hw.acpi.battery).
Reported by: Stefano Marinelli
Tested by: Stefano Marinelli
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D44818
(cherry picked from commit 2e850b832f5d2adb9b230d191277d67c00caaab9)
Trying to probe+attach the child device at the point it is added comes
before the syscon handle is set up (if relevant). It will therefore be
unavailable to the attach method which is expecting it, and the first
attempt to attach the device will fail.
Just rely on the call to bus_generic_attach() at the end of the function
to perform probe+attach of dev's children.
Reviewed by: manu
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44268
(cherry picked from commit accda781531788a814bc438e1e96ef544c12aeaf)
This is standard practice for clock drivers that register clocks
dynamically. Nothing else uses the CLK_DEBUG macro.
The result is that the name and frequency of the fixed clock is printed
for a verbose boot, which may aid in debugging.
Reviewed by: manu
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44265
(cherry picked from commit 6e66bb9fc3d026765113fa1258cd12292da9309a)
We may attach several of these devices, but there is no meaningful
information added to dmesg. For example:
ofwbus0: <Open Firmware Device Tree>
clk_fixed0: <Fixed clock> on ofwbus0
clk_fixed1: <Fixed clock> on ofwbus0
clk_fixed2: <Fixed clock> on ofwbus0
clk_fixed3: <Fixed clock> on ofwbus0
clk_fixed4: <Fixed clock> on ofwbus0
clk_fixed5: <Fixed clock> on ofwbus0
clk_fixed6: <Fixed clock> on ofwbus0
clk_fixed7: <Fixed clock> on ofwbus0
clk_fixed8: <Fixed clock> on ofwbus0
clk_fixed9: <Fixed clock> on ofwbus0
clk_fixed10: <Fixed clock> on ofwbus0
clk_fixed11: <Fixed clock> on ofwbus0
To reduce this noise, quiet the devices for by default. For verbose
boot, the message will be emitted.
Reviewed by: manu
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44266
(cherry picked from commit 1cb9f6f6413e9d242de47e730ec7d4ce3e5688fe)
If the call to clknode_get_freq() returns an error (unlikely), report
this, rather than printing the error code as the clock frequency.
If the clock has no parent (e.g. a fixed reference clock), print "none"
rather than "(NULL)(-1)". This is a more human-legible presentation of the
same information.
Reviewed by: manu
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44267
(cherry picked from commit 08635c51d1e34f8a3e42c7cf35dc7264a5b68118)
The snd_clone framework does not exist as of
e8c0d15a64fadb4a330f2da7244becaac161bb70 ("sound: Get rid of snd_clone
and use DEVFS_CDEVPRIV(9)"), so remove leftover references to it from
unit.c.
Sponsored by: The FreeBSD Foundation
MFC after: 2 months
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D44758
(cherry picked from commit 068c675ca7aec11d3546c3f908e842a7eca2ccae)
