The 'while' part corresponding to the 'do' was missing.
Did not notice the problem as later commits using it have been stashed
and never reworked up to now, and it is currently unused in the tree.
While here, fix spacing after the '#define' in the !(_KERNEL &&
INVARIANS) part.
Fixes: 34740937f7 ("queue: New debug macros for STAILQ")
MFC after: 1 minute
Sponsored by: The FreeBSD Foundation
vm_page_alloc() just calls vm_page_alloc_after(), after it has found
the predecessor of a page parameter. Many callers of vm_page_alloc()
already know that predecessor. Letting them pass that to
vm_page_alloc_after() directly could save a little redundant
calculation.
Reviewed by: alc
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D49103
Currently af-to works only on inbound interface by creating a reversed
NAT state key which is used to match traffic returning on the outbound
interface.
Such limitation is not necessary. When an af-to state is created
for an outbound rule do not reverse the NAT state key, making it work
just like if it was created for a normal NAT rule. Depending on firewall
design it might be easier and more natural to use af-to on the outbound
interface.
Reviewed by: kp
Approved by: kp (mentor)
Sponsored by: InnoGames GmbH
Differential Revision: https://reviews.freebsd.org/D49122
Set the default refill threshod to be one quarter of the rx queue
length. User can change this value with hw.mana.rx_refill_thresh
in loader.conf. It improves the rx completion handling by saving
10% to 15% of overall time with this change.
Tested by: whu
MFC after: 2 weeks
Sponsored by: Microsoft
The isi_txrate field is 8 bits and only represents legacy/HT rates.
So to avoid logging a warning, only populate if it's a legacy/HT
rate.
Differential Revision: https://reviews.freebsd.org/D48616
This is one of the two obvious left-over dot11rate lookups that trigger
a debug print. (The other is get_sta_info()).
* Change ieee80211_rate2media() to use the passed in ieee80211_node_txrate
and use the rate type field to see if it's legacy/ht or vht.
* .. and (I hope!) actually handle the VHT rate correctly.
* Change the callers of ieee80211_rate2media() to use the new static
initialisers.
For the one spot in ieee80211_ht.c which uses the HT initialiser, it should
just be a straight up mechanical change that correctly sets the HT MCS
rate.
For the rest of them in ieee80211.c, they're doing table initialisation
for the media types / rates, and it's currently very focused on legacy
rates. So just leave that all as-is for now with a mechanical change.
Differential Revision: https://reviews.freebsd.org/D48615
Update ieee80211_node_get_txrate_mbit() to use
ieee80211_phy_vht_get_mcs_kbit() to calculate VHT rates.
For now just assume long-GI; I'd have to go and do some extra
work to figure out which short/long GI flag to use.
Differential Revision: https://reviews.freebsd.org/D48613
This is a simple implementation, similar to HT, to generate
VHT MCS rates for testing.
I've verified it seems to do the right thing through
MCS 0..9 and NSS 1..2. It's not very optimal - same issues as
with 11n - but it at least now fully tests the 11ac TX path in
rtwn and the tx rate refactoring.
Differential Revision: https://reviews.freebsd.org/D48611
Refactor amrr_node_init() into HT and legacy paths, clean up the
printing to be a bit clearer about the selected rates.
This is precursor work to setting VHT rates in ni->ni_txrate .
Differential Revision: https://reviews.freebsd.org/D48429
Split the amrr_update() routine into HT and legacy paths.
Currently they're the same, minus HT / non-HT specific comments
and some logging changes.
HT rates don't monotonically go up (ie, going MCS 7 -> MCS 8 is wrong,
as MCS8 is "just" two stream MCS0) and failing a rate by a little
shouldn't necessarily preclude testing the next rate up.
This should be a no-op, besides the logging changes.
Locally tested:
* RTL8192CU, STA mode
Differential Revision: https://reviews.freebsd.org/D48248
Reviewed by: bz, thj
Introduce ieee80211_vht_node_check_tx_valid_mcs(), which takes the
node, bandwidth, NSS and MCS and validates whether that is possible
to TX to the given node.
Differential Revision: https://reviews.freebsd.org/D48610
Reviewed by: bz, thj
* add a node VHT transmit function, which configures the parameters
accordingly.
* add a node VHT transmit function which just copies in another
ieee80211_node_txrate struct.
Differential Revision: https://reviews.freebsd.org/D48609
Reviewed by: bz
Not all NSS / MCS / channel bandwidth combinations are valid.
This will be important for rate control and transmit rate
setup (eg static management, unicast, multicast rates.)
This is based on 802.11-2020 Section 21.5 (Parameters for VHT-MCSs.)
Differential Revision: https://reviews.freebsd.org/D48608
Reviewed by: bz
Implement ieee80211_setup_vht_rates() - calculate the intersection between
the peers advertised RX VHT MCS map and the vap's configured TX map.
Whilst here, remove the unused vhtcap/vhtinfo fields; they're
already populated in the ieee80211_node before ieee80211_setup_vht_rates()
is called.
Differential Revision: https://reviews.freebsd.org/D48607
Reviewed by: bz
Migrate the transmit path to use ieee80211_node_get_txrate(), and handle
VHT rates.
Nothing is currently setting VHT rates, but the driver should now
be ready.
Differential Revision: https://reviews.freebsd.org/D48606
Reviewed by: bz
ieee80211_node_get_txrate() populates the passed-in ieee80211_node_txrate with
the current rate configuration.
This is a no-op - nothing is yet setting VHT rates.
Differential Revision: https://reviews.freebsd.org/D48605
Reviewed by: bz
* create struct ieee80211_node_txrate, which represents both
the existing legacy / HT rates, and makes space for VHT rates
* convert the ieee80211_node_* routines that manipulate the txrate
field to use the new format
* return OFDM6 for now if a VHT rate is set but the driver calls
ieee80211_node_get_txrate_dot11rate(). It SHOULD be the lowest
available rate - which for 11b will be a CCK rate, for
turbo/half/quarter will be different rates! - but this is just
for development.
This should be a no-op for existing drivers and rate control, as
everything now uses the accessor functions instead of directly
accessing ni->ni_txrate.
Locally tested:
* RTL8821AU, STA mode (5GHz VHT/40)
Differential Revision: https://reviews.freebsd.org/D48604
Reviewed by: bz, thj
There are only a few places where the returned rix is used:
* linuxkpi - logging
* bwi/bwn - used for finding a fallback rate to choose, which
honestly should be returned by the ratectl API
* iwm - building the rateset to program into firmware
Everyone else uses the dot11rate value in ni->ni_txnode.
This is a precursor for VHT and later rate support; where currently
there aren't rate tables in ieee80211_phy.c for VHT and later
rates.
Although it's likely doable to add tables for VHT, 11ax and MU-OFDMA
(HE) rates are sufficiently larger/different to just not fit in the
current scheme without more refactoring.
Differential Revision: https://reviews.freebsd.org/D48603
Reviewed by: bz, thj
This just mechanically converts things.
* For linuxkpi, it was just used for display.
* For uath, it was just used for display, as firmware
doesn't report it up.
Differential Revision: https://reviews.freebsd.org/D48602
Reviewed by: bz, thj
The summary:
* Refactor ni_txrate access into ieee80211_node_get_txrate_dot11rate()
and ieee80211_node_set_txrate_dot11rate(). These wrap the ni->ni_txrate
access and will eventually be able to do runtime sanity checks and
fallback where necessary.
* Refactor ieee80211_node_get_txrate_kbit() from the ioctl code which
sets isi_txmbps (which is in 0.5Mbit/s units.) This new routine
returns the TX rate in kbit/s units.
* Also use ieee80211_node_get_txrate_kbit() in various places in the
code where the dot11rate was turned into a Mbit/sec value, which was
very wrong for HT (but also only used for logging, so it didn't
have an effect on normal runtime.)
* Mb -> Mbit/s
The long version:
The current ni->ni_txrate value is what net80211's phy code
calls a 'dot11rate'. Inside the ieee80211_phy.c tables you'll
find a bunch of tables which represent:
* for legacy rates its in 1/2 mbit units.
* for turbo (Atheros 40MHz OFDM) it's the non-turbo rates, but the
turbo rate speed in kbit/sec.
* for 802.11n rates its the MCS, starting at 0x80.
However there are a couple of catches with this:
* Basic rates are represented in the pre-11n rates using the high bit
(IEEE80211_RATE_BASIC)
* 11n rates are also represented using the high bit (IEEE80211_RATE_MCS)
Now, ni->ni_txrate will clear the IEEE80211_RATE_BASIC flag before
storing it, so if the high bit exists it must be an 802.11n rate.
However, there's still a bunch of code everywhere that purposefully
filters that out.
The goals of this commit:
* Provide an easy API to migrate existing drivers and other consumers
to - ieee80211_node_get_txrate_dot11rate() is defined as "will return
the normal legacy or HT rate" so all the existing code can work.
* Lay the ground work for extending ni_txrate (and a rate representation
in general) that can represent legacy, HT, VHT, EHT, HE, etc rates.
* Create a central place where ni_txrate is updated from rate control,
drivers that will update ni_txrate itself, and consumers,
so we can provide some basic runtime checks / logging as VHT, EHT, HE,
etc rates are eventually added.
For example, a VHT driver will eventually receive VHT rates, but an
existing HT driver will not, so the API should log and return a
sensible default when something like a VHT rate shows up on a HT only
device.
The rate control code currently returns a rix, and sets ni_txrate to the
dot11rate. Drivers can choose either. However, choosing the rix is
risky because you need to know if it's the ni_rates or ni_htrates, which
requires a lot of duplicate work that lines up consistently at all
layers (see the AMRR code for an example.)
Differential Revision: https://reviews.freebsd.org/D48601
Reviewed by: bz, thj
Since 9d5c83a0b8 pf depends on the crypto module (for SHA512_*).
Explicitly list this dependency.
PR: 285019
Sponsored by: Rubicon Communications, LLC ("Netgate")
Compile in the VHT compat code by default even though no one will make
use of it yet.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Tested with: iwlwifi AX210 (NOHT, HT20, HT40, VHT20, VHT40, VHT80)
If HT is enabled but not using CHW=40 set CHW=20 to make sure we do
not get stuck on any other value.
If VHT and the VHT Operation element Channel Width field is 0
(use 20/40) do not update the bandwidth but stick with what HT selected.
This is better than disabling VHT alltogether for 20/40 and allows us
to work on VHT20 and VHT40 APs it seems.
We will have to do more work to can align with the chanctx or deal with
Operating Mode Notification Action frames in LinuxKPI or net80211.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Compile in the HT compat code by default even though no one will make
use of it yet.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Tested with: iwlwifi AX210 (NOHT, HT20 and HT40)
Bring in code to call into rs-fw.c functionality for firmware
supported rate select.
Anything before AX200 (firmware matching iwlwiif-[0-9]*.ucode) will
still need further implementation, and so does iwl_mvm_rs_tx_status().
These bits marked with compat.linuxkpi.80211.debug TODO()s for now.
Implement some lindebugfs bits to gather more statistical information.
Sponsored by: The FreeBSD Foundation
Obtained from: bz_wifi_11n branch (partially)
MFC after: 3 days
Add a new hw_all_ok() routine and use it to avoid hardware access in the
public control interfaces (ifnet ioctls, ifmedia calls, etc.). Continue
to use hw_off_limits() in the private ioctls/sysctls and other debug
code. Retire adapter_stopped() as it's of no use by itself.
This fixes problems where ifnet slow-path operations would enter a
synch_op just before set_adapter_hwstatus(false) and touch the hardware
when it's not safe to do so.
MFC after: 1 week
Sponsored by: Chelsio Communications
Amazon EC2 m7i cloud instances use PCI hotplug rather than ACPI
hotplug. The card is removed and detach is called to remove the drive
from the system. The hardware is no longer present at this point, but
the bridge doesn't translate the now-missing hardware reads to all ff's
leading us to conclude the hardware is there and we need to do a proper
shutdown of it. Fix this oversight by asking the bridge if the device is
still present as well. We need both tests since some systems one cane
remove the card w/o a hotplug event and we want to fail-safe in those
cases.
Convert gone to a bool while I'm here and update a comment about
shutting down the controller and why that's important.
Tested by: cperciva
Sponsored by: Netflix
The comment and rationale behind choosing CHN_INSERT_SORT_DESCEND()
instead of CHN_INSERT_SORT_ASCEND() are no longer relevant as of FILLME
("sound: Allocate vchans on-demand").
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D48962
The mechanism of acquiring SD_F_BUSY in pcm_init() and releasing it in
pcm_register() is a leftover from the previous device creation scheme,
where pcm_init() (previously pcm_register()) would create the sysctl
nodes, as well as the device node. In this scenario, acquiring SD_F_BUSY
was necessary, in order to avoid races in case the device was accessed
before it was ready for use. Commit 66f3eb14e9 ("sound: Move sysctl
and /dev/dspX creation to pcm_setstatus()") fixed this issue, so we can
simplify things now. Only acquire SD_F_BUSY in pcm_addchan(), because
chn_init() expects to be called with SD_F_BUSY acquired.
While here, move the sndstat_register() call further down to be more
robust.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D48482
This gives us a slight performance boost since we do not have to go
through chn_setparam() and the driver functions.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch, emaste
Differential Revision: https://reviews.freebsd.org/D48012
It's a no-op. There is no lock associated with the buffer.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D48008
vchan_getparentchannel() is used by various vchan sysctl functions to
fetch the first primary channel. However, this assumes that all devices
have only one primary channel per direction. If a device does not meet
this assumption, then the sysctl functions will be applying the
configurations on the first primary channel only.
Since we now have the "primary" channel sublist, we can retire
vchan_getparentchannel() and iterate through the "primary" list in each
sysctl function and apply the settings to all primary channels.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D48336
Refactor pcm_chnalloc() and merge with parts of vchan_setnew() (now
removed) and dsp_open()’s channel creation into a new dsp_chn_alloc()
function. The function is responsible for either using a free HW channel
(if vchans are disabled), or allocating a new vchan.
Clean up allocated vchans associated with a given dsp_cdevpriv on
dsp_close() instead of leaving them unused.
hw.snd.vchans_enable (previously hw.snd.maxautovchans) and
dev.pcm.X.{play|rec}.vchans now work as tunables to only enable/disable
vchans, as opposed to setting their number and/or (de-)allocating
vchans. Since these sysctls do not trigger any (de-)allocations anymore,
their effect is instantaneous, whereas before we could have frozen the
machine (when trying to allocate new vchans) when setting
dev.pcm.X.{play|rec}.vchans to a very large value.
Create a new "primary" channel sublist so that we do not waste time
looping through all channels in dsp_chn_alloc(), since we are only
looking for a parent channel to either use, or add a new vchan to. This
guarantees a steady traversal speed, as the parent channels are most
likely going to be just a handful (2). What was currently in place was a
loop through the whole channel list, which meant that the traversal
would take longer the more channels were added to that list.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D47917
There is no good reason to initialize with AFMT_U8 at 8000Hz.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D48434
