Revert: LinuxKPI: switch jiffies and timer->expire to unsigned long
There are possible problems when jiffies (ticks) which still are int
wrap around. Also given this did not touch every single place some
checks may be broken now.
Reported by: markj
This reverts commit fd27f86dd71b7ff1df6981297095b88d1d29652e.
libmagic: Unbreak for older FreeBSD releases.
byteswap.h is introduced in FreeBSD 13.2 but was not available in
earlier versions. In order to support upgrading from an earlier
FreeBSD release we would need to tell the build system that fact.
PR: bin/273736
Reported by: philip
MFC after: 3 days
rtwn: set the maximum A-MPDU size correctly for RTL8812AU/RTL8821AU
The vendor driver sets it to 64k or 128k depending upon chipset,
along with bit 31 being set in hal/rtl8812a_hal_init.c:SetHwReg8812A().
Differential Revision: https://reviews.freebsd.org/D48118
Obtained from: https://github.com/lwfinger/rtl8812au
Reviewed by: bz
rtwn: don't set the RTS/CTS primary channel field for RTL8812AU/RTL8821AU
According to the rtl8812au reference driver, this seems to control
the bandwidth used by lower-bandwidth frames when transmitted in
a higher bandwidth channel. For example, transmitting a 20MHz frame
on an 80MHz channel (eg in hostap mode) is doable, but you may want
to at least duplicate the RTS/CTS exchange across all four 20MHz
subchannels, AND perhaps duplicate the 20MHz frame.
I haven't fired this up with a spectrum analyser to see what the
result is.
The vendor driver doesn't bother with this and it doesn't change
performance. My guess is that for modes like AP mode we MAY wantto
be able to control the RTS/CTS bandwidth choices rather than letting
the firmare do it, but we're not there yet.
The rtl8812au code in hal/rtl8812a_xmit.c:SCMapping_8812() has
the gory details, but then the one place it's used just has it
[5 lines not shown]
LinuxKPI: switch jiffies and timer->expire to unsigned long
It seems these functions work with unsigned long and not int in Linux.
Start simply replacing the int where I came across it while debugging
a wireless driver timer modification. Also sprinkle in some "const".
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D48318
LinuxKPI: 802.11: improve the IMPROVE_HT() macro
Let the macro take a format string and arguments and
add __func__, __LINE__ to the output.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
net80211 / LinuxKPI 802.11: correct enum ieee80211_sta_rx_bw
When moving the enum from LinuxKPI to net80211 it got adjusted to be
used in net80211 style in order to use it with a print_mask (%b).
Turns out that change broke assumptions given the minimum value of
BW_20 no longer was 0. Adjust it back to a plain enum starting at 0
and use an inline function to convert to value names.
Pointy hat to: bz
Fixes: ca389486a9599768e0ba69dca13c208020623083
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D48375
lindebugfs: Export symbols
We currently rely on the kernel linker resolving undefined references
against local symbols from other kernel modules. Be explicit about the
symbols to export, in advance of changing that behaviour.
PR: 207898
Reviewed by: kib, bz
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D47980
(cherry picked from commit c3d2c959b5c0ea05d6e5162def35d51ec267590c)
kernel: Clarify kern.elfNN.nxstack sysctl description
The nxstack sysctl controls processing of the PT_GNU_STACK segment,
not directly whether or not the stack is executable.
Reviewed by: kib, shurd
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48221
(cherry picked from commit 837feb4d05c2dccafa1698649b58f7b7fdc59c54)
net80211: (v)ht: use macros at hand
Rather than duplicating the manual logic here and leaving a comment,
use the self-explanatory macros we already have.
No functional changes intended.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D48359
lib80211: regdomain: add the two other 160MHz bands
ETSI had one 160Mhz band in regdomain but the other two were missing.
Add them. I am always confused that the bands use the center frequency
of the 20Mhz edge channels rather than the actual edges so it seems we
are only configuring 140Mhz instead of 160Mhz.
We will have to go through the entire regdomain file one
day and make sure to verify all the power levels.
Sponsored by: The FreeSBD Foundation
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D48356
net80211: add missing 80Mhz and 160Mhz channel ranges
We have two arrays, one for 80Mhz and one for 160Mhz. Both were lacking
frequency ranges for more possibly available configurations (the other
bits of what is valid are for regdomain to set right).
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Fixes: 67f4aa3878efa, 04e7bb08a5750
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D48357
ifconfig: make -vht work
Also hide the other vht options on -vht and only show vht40/80/160/80p80
when vht is enabled.
While here fix some whitespace and comments.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian, emaste
Differential Revision: https://reviews.freebsd.org/D48326
LinuxKPI: 802.11: turn on debugfs for iwlwifi and rtw88
Make iwlwifi compile with debugfs after the last updates and turn it on
for both iwlwifi and rtw88 in order to be able to get at least some
useful information on driver/firwmare state.
Sponsored by: The FreeBSD Foundation
MFC after: 10 days
mi_switch.9: Remove cpu_switch, cpu_throw
cpu_machdep.9 was added to document cpu_*, but cpu_switch and cpu_throw
were already documented in mi_switch.9, and MLINKed. cpu_machdep.9
seems like the correct place for this, so remove them from mi_switch.9.
Some of the removed text was stale, although there are few notes that
ought to be added to cpu_machdep.9 in a future commit.
Reported by: tools/pkgbase/metalog_reader.lua
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
Fixes: 9c87cbbcaaed ("cpu_machdep.9: New manpage describing the semantics of several cpu_*")
Differential Revision: https://reviews.freebsd.org/D48360
pci_find_cap_method(): limit number of iterations for finding a capability
Powered down device might return 0xff of extended config registers
reads, causing loop.
PR: 283815
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D48348
LinuxKPI: 802.11: add a print mask for ieee80211_rx_status_flags bits
Add a print mask for use with %b to aid debugging. It is a lot easier
to read names than numbers.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
bhyve: Implement the libslirp notify callback
libslirp can invoke a callback when received data is removed from a
socket buffer, generally because the guest ACKed some data. Previously
it didn't do anything, but it needs to wake up the poll thread to get
reasonable throughput.
Suppose one is using scp to copy data into a guest filesystem via the
slirp backend. Data is received on libslirp's socket, which we poll for
data in slirp_pollfd_td_loop(). That data gets buffered in priv->pipe,
and eventually is placed in the device model's RX rings by the backend's
mevent handler. When implementing TCP, libslirp holds on to a copy of
data until it's ACKed by the guest via slirp_send(), at which point it
drops that data and invokes the notify callback.
The initial implementation of this backend didn't take into account the
fact that slirp_pollfds_fill() will not add libslirp's socket to the
pollfd set if more than a threshold amount of data is already buffered.
Then poll() needs to time out before the backend sends more data to the
[7 lines not shown]
bhyve: Use a non-blocking read in slirp_recv()
When using the slirp backend with the e1000 frontend, I otherwise get
hangs in readv(), caused by the e1000 emulation not checking whether
bytes are available before trying to read them. In particular, that
device model expects the recv callback to return 0 if no bytes are
available, and with slirp it would end up blocking forever. The virtio
device model uses the peek_recvlen to check first, so I didn't notice
the problem when implementing the slirp backend.
Make the slirp backend more flexible to accommodate e1000.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D48164
makefs: Handle special file types when creating a zpool
Previously, anything other than a regular file, directory or symlink
would cause makefs to exit with an assertion failure. Make it a bit
more resilient to user error: print a warning and skip the file. Add a
regression test wherein we create an image from a devfs mount.
PR: 283583
MFC after: 2 weeks
ifconfig: remove debug printfs from set80211vhtconf()
Anyone testing VHT options would wonder about these extra two printfs
by now. Remove them from the tree before I have to do so locally again
in another branch.
Sponsored by: The FreeBSD Foundation
Fixes: e9bb7f9aa1b4f
MFC after: 1 week
Reviewed by: adrian, emaste
Differential Revision: https://reviews.freebsd.org/D48319
LinuxKPI 802.11 / rtw88: make packets flow again
In 886653492945f we added checks for packets to only go out if the
station is known to the firmware (amongst others) as there are
implications in drivers.
Unfortunately rtw88 does not support the mac80211 (*sta_state)() KPI
but only the fallback (*sta_add/remove)() in which case the station is
only added to firmware when going from AUTH to ASSOC. That means we
had no chance to get authenticated anymore.
The problem has existed since June in main and stable/14 but only now
was noticed in December with 14.2-R which makes me wonder.
I am still not entirely sure what implications the missing checks have
on all the other drivers using (*sta_state)() (or if they were really
needed in first place beyond txq_ready) but I have run a few days of
iwlwifi with this without extra trouble but I was not always able to
reproduce problems in the past. Also people are occasionally still
reporting the original "Invalid TXQ" error which indicates there is
[10 lines not shown]
libusb: fix hotplug sigbus
When a hotplug callback has been registered, and the program using
libusb is calling libusb_exit then the thread handler is set to
NO_THREAD which result in the variable controlling the loop the be set
to 0, it does a last pass through device available without having done
a scan, which result in a sigbus after it tried to unregister all the
devices.
directly break the loop instead and cleanup the list of devices
this fixes the tests with LGPLed libusb's hotplugtest program
MFC After: 3 days
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D48298
(cherry picked from commit ba5834b8e11fd002a663d083a464e397e76cb3a9)
