Re: initial iwx(4) 11ac patch for testing
On Wed, Mar 09, 2022 at 01:07:47PM +0100, Stefan Sperling wrote: > This patch adds initial 11ac support to the iwx(4) driver. > This means that 80MHz channels can be used. No other 11ac features > are enabled yet. > > This is not yet a patch which could be committed. Apart from debug > prints which need to go, there is a known issue found by dv@ where > this patch causes a firmware error, sysassert 0x20101A25. The reason > for this is not known. > It would help to get more testing to see if more clues can be found > based on where this error pops up. I cannot reproduce the error myself. > > When sending feedback, please be clear about which iwx(4) device and > which access point has been tested. Thanks! > > The patch works for me on AX200 and AX201 with a pepwave AC one mini AP, > although throughput is not much different to 11n 40MHz with this AP. > I tried this on my iwx. The performance increase is noticeable. It looks like it negotiated VHT-MCS9. I did see some 80MHz dmesg printfs but I'm not sure how to interpret them. LMK if you want more info. Before [ ID] Interval Transfer Bitrate [ 6] 0.00-1.00 sec 20.5 MBytes 172 Mbits/sec [ 6] 1.00-2.00 sec 22.6 MBytes 190 Mbits/sec [ 6] 2.00-3.00 sec 22.4 MBytes 187 Mbits/sec [ 6] 3.00-4.00 sec 22.6 MBytes 189 Mbits/sec [ 6] 4.00-5.00 sec 23.0 MBytes 193 Mbits/sec [ 6] 5.00-6.01 sec 22.5 MBytes 188 Mbits/sec [ 6] 6.01-7.00 sec 22.4 MBytes 188 Mbits/sec [ 6] 7.00-8.00 sec 22.2 MBytes 186 Mbits/sec [ 6] 8.00-9.00 sec 22.9 MBytes 193 Mbits/sec [ 6] 9.00-10.00 sec 22.9 MBytes 192 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 6] 0.00-10.00 sec 224 MBytes 188 Mbits/sec sender [ 6] 0.00-10.25 sec 224 MBytes 183 Mbits/sec receiver After [ ID] Interval Transfer Bitrate [ 6] 0.00-1.00 sec 35.7 MBytes 299 Mbits/sec [ 6] 1.00-2.00 sec 33.1 MBytes 278 Mbits/sec [ 6] 2.00-3.00 sec 36.1 MBytes 303 Mbits/sec [ 6] 3.00-4.00 sec 35.4 MBytes 296 Mbits/sec [ 6] 4.00-5.00 sec 36.5 MBytes 307 Mbits/sec [ 6] 5.00-6.00 sec 36.8 MBytes 309 Mbits/sec [ 6] 6.00-7.00 sec 37.2 MBytes 312 Mbits/sec [ 6] 7.00-8.00 sec 38.2 MBytes 321 Mbits/sec [ 6] 8.00-9.00 sec 34.0 MBytes 285 Mbits/sec [ 6] 9.00-10.00 sec 38.3 MBytes 322 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 6] 0.00-10.00 sec 361 MBytes 303 Mbits/sec sender [ 6] 0.00-10.20 sec 361 MBytes 297 Mbits/sec receiver iwx0 at pci0 dev 20 function 3 "Intel Wi-Fi 6 AX201" rev 0x20, msix iwx0: hw rev 0x350, fw ver 67.8f59b80b.0 iwx0: flags=808847 mtu 1500 lladdr x index 1 priority 4 llprio 3 groups: wlan egress media: IEEE802.11 autoselect (VHT-MCS9 mode 11ac) status: active ieee80211: join x chan 149 bssid x 77% wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp
ssh: xstrdup(): use memcpy(3)
The strdup(3) implementation in libc uses memcpy(3), not strlcpy(3). There is no upside to using strlcpy(3) here if we know the length of str before we copy it to the destination buffer. ... unless we're worried the length of str will change? Which would be very paranoid. But if that's the case we should be checking that the return value of strlcpy(3) equals len and calling fatal() if it isn't. ok? Index: xmalloc.c === RCS file: /cvs/src/usr.bin/ssh/xmalloc.c,v retrieving revision 1.36 diff -u -p -r1.36 xmalloc.c --- xmalloc.c 12 Nov 2019 22:32:48 - 1.36 +++ xmalloc.c 10 Mar 2022 01:06:54 - @@ -85,8 +85,7 @@ xstrdup(const char *str) len = strlen(str) + 1; cp = xmalloc(len); - strlcpy(cp, str, len); - return cp; + return memcpy(cp, str, len); } int
Re: riscv64: ld.lld is too picky on ABI mismatch
On Mon, Oct 25 2021, Jeremie Courreges-Anglas wrote:
> On Mon, Oct 25 2021, Patrick Wildt wrote:
>> Am Mon, Oct 25, 2021 at 11:43:55AM +0200 schrieb Mark Kettenis:
>>> > From: Jeremie Courreges-Anglas
>>> > Date: Sun, 24 Oct 2021 17:30:46 +0100
>>> >
>>> > clang(1) defaults to FP ABI but ld(1) -melf64lriscv doesn't. This is
>>> > a problem as soon as a port tries to use raw ld(1) -b binary to embed
>>> > data in a .o file.
>>> >
>>> > Downgrading this hard error to a warning seems more useful as far as the
>>> > ports tree is concerned. The diff below fixes
>>> > databases/postgresql-pllua and should also fix textproc/mupdf and
>>> > net/utox.
>>> >
>>> > There's another diff here: https://reviews.llvm.org/D106378
>>> > but it's slightly more complicated and it received seemingly negative
>>> > feedback. So I'm just using a minimal change to fit our needs.
>>> >
>>> > ok?
>>>
>>> I think we should try to avoid deviating from upstream as much as
>>> possible. And I agree with the folks who argue that the mismatching
>>> objects are created with the wrong tools.
>
> Well the only alternative they suggest is using assembly and .incbin.
> Maybe that works for the FreeBSD folks working on low-level stuff, but
> not so much as a general purpose tool to include binary data in builds.
>
>>> But if mortimer@ and
>>> patrick@ can deal with carrying this local modification I won't
>>> object.
>
> I can't speak for them but given the local changes we have in clang and
> lld land this two lines diff doesn't seem daunting. ;)
>
>> Well, I was about to send an LLVM 13 diff... so can we revisit this diff
>> when we're updated to LLVM 13?
I have added comments on https://reviews.llvm.org/D106378#3219454 but
the discussion has stalled again (I'll try to revive it).
I'm still using the diff below on the riscv64 ports build machines, and
I'd like to get rid of the burden of keeping it in my tree.
ok?
Index: ELF/Arch/RISCV.cpp
===
RCS file: /cvs/src/gnu/llvm/lld/ELF/Arch/RISCV.cpp,v
retrieving revision 1.1.1.3
diff -u -p -r1.1.1.3 RISCV.cpp
--- ELF/Arch/RISCV.cpp 17 Dec 2021 12:25:02 - 1.1.1.3
+++ ELF/Arch/RISCV.cpp 28 Jan 2022 09:11:18 -
@@ -124,8 +124,8 @@ uint32_t RISCV::calcEFlags() const {
target |= EF_RISCV_RVC;
if ((eflags & EF_RISCV_FLOAT_ABI) != (target & EF_RISCV_FLOAT_ABI))
- error(toString(f) +
-": cannot link object files with different floating-point ABI");
+ warn(toString(f) +
+": linking object files with different floating-point ABI");
if ((eflags & EF_RISCV_RVE) != (target & EF_RISCV_RVE))
error(toString(f) +
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: ipsec acquire mutex refcount
On 9.3.2022. 19:14, Alexander Bluhm wrote: > Hi, > > Hrvoje has hit a crash with IPsec acquire while testing the parallel > ip forwarding diff. Analysis with sashan@ concludes that this part > is not MP safe. Mutex and refcount should fix the memory management. > > Hrvoje: Could you test this diff? Hi, no problem. Give me 2 or 3 days to hit it properly...
Re: atomic read write
On Tue, Mar 08, 2022 at 04:55:56PM +0100, Alexander Bluhm wrote:
> Once we had the discussion where we need the READ_ONCE() macro. As
> modern C compiler has much freedom how to access memory, I came to
> the conclusion that it would be wise to use READ_ONCE() and
> WRITE_ONCE() everywhere when we use atomic operations variables.
> Using atomic operations on one side and do whatever the compiler
> thinks at the other side of the variable feels wrong.
>
> The rule use READ_ONCE, WRITE_ONCE, atomic_inc, atomic_dec consistently
> would be easy to follow. Thinking about where the compiler might
> reorder things and break MP code is much more complicated.
>
> Do we want to go this direction?
mvs@ mentioned that FreeBSD has atomic load and store instructions
for that. I decided to implement them as static inline functions
as they provide stronger type checks. Also I add them for int and
long only, everything else is not atomic.
> If yes, here is the change for struct refcnt and cond. While there
> rename the field to r_refs which is easier to grep.
Note that the _init functions do not need atomic operations. But
the whole idea is to make it consistent and have a simple rule. If
an MP variable locking is marked as atomic, use the atomic_ functions.
As a bonus alpha gets the membar it needs.
ok?
bluhm
Index: sys/dev/pci/if_iwm.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/dev/pci/if_iwm.c,v
retrieving revision 1.391
diff -u -p -r1.391 if_iwm.c
--- sys/dev/pci/if_iwm.c8 Feb 2022 14:24:36 - 1.391
+++ sys/dev/pci/if_iwm.c9 Mar 2022 18:52:52 -
@@ -9975,7 +9975,7 @@ iwm_init(struct ifnet *ifp)
generation = ++sc->sc_generation;
- KASSERT(sc->task_refs.refs == 0);
+ KASSERT(atomic_load_int(>task_refs.r_refs) == 0);
refcnt_init(>task_refs);
err = iwm_preinit(sc);
@@ -10116,7 +10116,7 @@ iwm_stop(struct ifnet *ifp)
iwm_del_task(sc, systq, >mac_ctxt_task);
iwm_del_task(sc, systq, >phy_ctxt_task);
iwm_del_task(sc, systq, >bgscan_done_task);
- KASSERT(sc->task_refs.refs >= 1);
+ KASSERT(atomic_load_int(>task_refs.r_refs) >= 1);
refcnt_finalize(>task_refs, "iwmstop");
iwm_stop_device(sc);
Index: sys/dev/pci/if_iwx.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/dev/pci/if_iwx.c,v
retrieving revision 1.134
diff -u -p -r1.134 if_iwx.c
--- sys/dev/pci/if_iwx.c21 Jan 2022 15:51:02 - 1.134
+++ sys/dev/pci/if_iwx.c9 Mar 2022 18:53:50 -
@@ -8017,7 +8017,7 @@ iwx_init(struct ifnet *ifp)
if (sc->sc_nvm.sku_cap_11n_enable)
iwx_setup_ht_rates(sc);
- KASSERT(sc->task_refs.refs == 0);
+ KASSERT(atomic_load_int(>task_refs.r_refs) == 0);
refcnt_init(>task_refs);
ifq_clr_oactive(>if_snd);
ifp->if_flags |= IFF_RUNNING;
@@ -8139,7 +8139,7 @@ iwx_stop(struct ifnet *ifp)
iwx_del_task(sc, systq, >mac_ctxt_task);
iwx_del_task(sc, systq, >phy_ctxt_task);
iwx_del_task(sc, systq, >bgscan_done_task);
- KASSERT(sc->task_refs.refs >= 1);
+ KASSERT(atomic_load_int(>task_refs.r_refs) >= 1);
refcnt_finalize(>task_refs, "iwxstop");
iwx_stop_device(sc);
Index: sys/kern/kern_synch.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/kern/kern_synch.c,v
retrieving revision 1.182
diff -u -p -r1.182 kern_synch.c
--- sys/kern/kern_synch.c 19 Feb 2022 23:56:18 - 1.182
+++ sys/kern/kern_synch.c 9 Mar 2022 18:57:53 -
@@ -804,7 +804,7 @@ sys___thrwakeup(struct proc *p, void *v,
void
refcnt_init(struct refcnt *r)
{
- r->refs = 1;
+ atomic_store_int(>r_refs, 1);
}
void
@@ -813,10 +813,10 @@ refcnt_take(struct refcnt *r)
#ifdef DIAGNOSTIC
u_int refcnt;
- refcnt = atomic_inc_int_nv(>refs);
+ refcnt = atomic_inc_int_nv(>r_refs);
KASSERT(refcnt != 0);
#else
- atomic_inc_int(>refs);
+ atomic_inc_int(>r_refs);
#endif
}
@@ -825,7 +825,7 @@ refcnt_rele(struct refcnt *r)
{
u_int refcnt;
- refcnt = atomic_dec_int_nv(>refs);
+ refcnt = atomic_dec_int_nv(>r_refs);
KASSERT(refcnt != ~0);
return (refcnt == 0);
@@ -844,10 +844,10 @@ refcnt_finalize(struct refcnt *r, const
struct sleep_state sls;
u_int refcnt;
- refcnt = atomic_dec_int_nv(>refs);
+ refcnt = atomic_dec_int_nv(>r_refs);
while (refcnt) {
sleep_setup(, r, PWAIT, wmesg, 0);
- refcnt = r->refs;
+ refcnt = atomic_load_int(>r_refs);
sleep_finish(, refcnt);
}
}
@@ -855,13 +855,13 @@ refcnt_finalize(struct refcnt *r, const
void
cond_init(struct cond *c)
{
- c->c_wait = 1;
+ atomic_store_int(>c_wait, 1);
}
ipsec acquire mutex refcount
Hi,
Hrvoje has hit a crash with IPsec acquire while testing the parallel
ip forwarding diff. Analysis with sashan@ concludes that this part
is not MP safe. Mutex and refcount should fix the memory management.
Hrvoje: Could you test this diff?
ok?
bluhm
Index: net/pfkeyv2.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/net/pfkeyv2.c,v
retrieving revision 1.232
diff -u -p -r1.232 pfkeyv2.c
--- net/pfkeyv2.c 8 Mar 2022 22:30:38 - 1.232
+++ net/pfkeyv2.c 9 Mar 2022 18:11:10 -
@@ -1591,7 +1591,8 @@ pfkeyv2_send(struct socket *so, void *me
case SADB_X_ASKPOLICY:
/* Get the relevant policy */
NET_LOCK();
- ipa = ipsec_get_acquire(((struct sadb_x_policy *)
headers[SADB_X_EXT_POLICY])->sadb_x_policy_seq);
+ ipa = ipsec_get_acquire(((struct sadb_x_policy *)
+ headers[SADB_X_EXT_POLICY])->sadb_x_policy_seq);
if (ipa == NULL) {
rval = ESRCH;
NET_UNLOCK();
@@ -1600,6 +1601,7 @@ pfkeyv2_send(struct socket *so, void *me
rval = pfkeyv2_policy(ipa, headers, , _sz);
NET_UNLOCK();
+ ipsec_unref_acquire(ipa);
if (rval)
mode = PFKEYV2_SENDMESSAGE_UNICAST;
Index: netinet/ip_ipsp.h
===
RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/ip_ipsp.h,v
retrieving revision 1.236
diff -u -p -r1.236 ip_ipsp.h
--- netinet/ip_ipsp.h 8 Mar 2022 22:30:38 - 1.236
+++ netinet/ip_ipsp.h 9 Mar 2022 17:46:22 -
@@ -45,6 +45,7 @@
* I immutable after creation
* a atomic operations
* N net lock
+ * A ipsec_acquire_mtx
* F ipsec_flows_mtx
* m tdb_mtx fields of struct tdb
* p ipo_tdb_mtx link policy to TDB global mutex
@@ -251,12 +252,15 @@ struct ipsec_acquire {
u_int32_t ipa_seq;
struct sockaddr_encap ipa_info;
struct sockaddr_encap ipa_mask;
+ struct refcnt ipa_refcnt;
struct timeout ipa_timeout;
- struct ipsec_policy *ipa_policy;
- TAILQ_ENTRY(ipsec_acquire) ipa_ipo_next;
- TAILQ_ENTRY(ipsec_acquire) ipa_next;
+ struct ipsec_policy *ipa_policy;/* [A] back pointer */
+ TAILQ_ENTRY(ipsec_acquire) ipa_ipo_next; /* [A] per policy */
+ TAILQ_ENTRY(ipsec_acquire) ipa_next; /* [A] global list */
};
+TAILQ_HEAD(ipsec_acquire_head, ipsec_acquire);
+
struct ipsec_policy {
struct radix_node ipo_nodes[2]; /* radix tree glue */
struct sockaddr_encap ipo_addr;
@@ -287,9 +291,9 @@ struct ipsec_policy {
struct ipsec_ids*ipo_ids;
- TAILQ_HEAD(ipo_acquires_head, ipsec_acquire) ipo_acquires; /* List of
acquires */
- TAILQ_ENTRY(ipsec_policy) ipo_tdb_next; /* List TDB policies */
- TAILQ_ENTRY(ipsec_policy) ipo_list; /* List of all policies
*/
+ struct ipsec_acquire_head ipo_acquires; /* [A] List of acquires */
+ TAILQ_ENTRY(ipsec_policy) ipo_tdb_next; /* [p] List TDB policies */
+ TAILQ_ENTRY(ipsec_policy) ipo_list; /* List of all policies */
};
#defineIPSP_POLICY_NONE0x /* No flags set */
@@ -682,6 +686,7 @@ ssize_t ipsec_hdrsz(struct tdb *);
void ipsec_adjust_mtu(struct mbuf *, u_int32_t);
void ipsec_set_mtu(struct tdb *, u_int32_t);
struct ipsec_acquire *ipsec_get_acquire(u_int32_t);
+void ipsec_unref_acquire(struct ipsec_acquire *);
intipsec_forward_check(struct mbuf *, int, int);
intipsec_local_check(struct mbuf *, int, int, int);
Index: netinet/ip_spd.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/ip_spd.c,v
retrieving revision 1.114
diff -u -p -r1.114 ip_spd.c
--- netinet/ip_spd.c8 Mar 2022 22:30:38 - 1.114
+++ netinet/ip_spd.c9 Mar 2022 17:57:29 -
@@ -43,10 +43,11 @@ int ipsp_spd_inp(struct mbuf *, struct i
struct tdb **);
intipsp_acquire_sa(struct ipsec_policy *, union sockaddr_union *,
union sockaddr_union *, struct sockaddr_encap *, struct mbuf *);
-struct ipsec_acquire *ipsp_pending_acquire(struct ipsec_policy *,
- union sockaddr_union *);
-void ipsp_delete_acquire_timo(void *);
+intipsp_pending_acquire(struct ipsec_policy *, union sockaddr_union *);
+void ipsp_delete_acquire_timer(void *);
+void ipsp_delete_acquire_locked(struct ipsec_acquire *);
void ipsp_delete_acquire(struct ipsec_acquire *);
+void ipsp_unref_acquire_locked(struct ipsec_acquire *);
struct pool ipsec_policy_pool;
struct pool ipsec_acquire_pool;
@@
Re: Add kernel stack trace saving for riscv64
On Wed, Mar 09, 2022 at 08:40:50AM +0100, Jeremie Courreges-Anglas wrote: > On Tue, Mar 08 2022, Visa Hankala wrote: > > This patch adds kernel stack trace saving for riscv64, for the benefit > > of dt(4) and witness(4). > > Nice! > > > The unwinder is slow because of the symbol > > lookup, but this can be tweaked later. > > A dumb approach that appears to work: add > cpu_exception_handler_supervisor_end and cpu_exception_handler_user_end > symbols, and perform a range check. Yes, using extra symbols and checking ranges has been an option. It does not look nice but seems less intrusive than making the exception entry points preserve, or rather improvise, the chain of callframes. I have to withdraw the patch for now as it does not seem reliable.
Re: initial iwx(4) 11ac patch for testing
On Wed, Mar 09, 2022 at 01:07:47PM +0100, Stefan Sperling wrote:
> This patch adds initial 11ac support to the iwx(4) driver.
> This means that 80MHz channels can be used. No other 11ac features
> are enabled yet.
>
> This is not yet a patch which could be committed. Apart from debug
> prints which need to go, there is a known issue found by dv@ where
> this patch causes a firmware error, sysassert 0x20101A25. The reason
> for this is not known.
> It would help to get more testing to see if more clues can be found
> based on where this error pops up. I cannot reproduce the error myself.
>
> When sending feedback, please be clear about which iwx(4) device and
> which access point has been tested. Thanks!
>
> The patch works for me on AX200 and AX201 with a pepwave AC one mini AP,
> although throughput is not much different to 11n 40MHz with this AP.
I can't test the functionality of the patch, because I don't own Intel
hardware and proper AP, but during 'git apply' process it warned about
improper whitespacing, the patch for this is inlined at the end of the
mail (need to be applied above your patch).
>
> /*
> + * Install received VHT caps information in the node's state block.
> + */
> +void
> +ieee80211_setup_vhtcaps(struct ieee80211_node *ni, const uint8_t *data,
> +uint8_t len)
> +{
> + if (len != 12)
> + return;
> +
> + ni->ni_vhtcaps = (data[0] | (data[1] << 8) | data[2] << 16 |
> + data[3] << 24);
> + ni->ni_vht_rxmcs = (data[4] | (data[5] << 8));
> + ni->ni_vht_rx_max_lgi_mbit_s = ((data[6] | (data[7] << 8)) &
> + IEEE80211_VHT_MAX_LGI_MBIT_S_MASK);
> + ni->ni_vht_txmcs = (data[8] | (data[9] << 8));
> + ni->ni_vht_tx_max_lgi_mbit_s = ((data[10] | (data[11] << 8)) &
> + IEEE80211_VHT_MAX_LGI_MBIT_S_MASK);
> +
> + ni->ni_flags |= IEEE80211_NODE_VHTCAP;
> +}
I understand that this function do things like ieee80211_setup_htcaps()
(HT, 802.11n), which is mature, working and stable, but is there a
reason not to return 0 on error, 1 on success, and check it in the
caller (like in ieee80211_setup_vhtop())?
> +/* Check if the peer supports VHT short guard interval (SGI) on 160 MHz. */
> +static inline int
> +ieee80211_node_supports_vht_sgi160(struct ieee80211_node *ni)
> +{
> + return ieee80211_node_supports_vht(ni) &&
> + (ni->ni_vhtcaps & IEEE80211_VHTCAP_SGI160);
> +}
This function is unused.
The patch for whitespacing:
diff --git sys/dev/pci/if_iwx.c sys/dev/pci/if_iwx.c
index a56c59f82c8..9efa429df07 100644
--- sys/dev/pci/if_iwx.c
+++ sys/dev/pci/if_iwx.c
@@ -5384,7 +5384,7 @@ iwx_tx_fill_cmd(struct iwx_softc *sc, struct iwx_node *in,
rate_flags |= IWX_RATE_MCS_CHAN_WIDTH_80;
if (ieee80211_node_supports_vht_sgi80(ni))
rate_flags |= IWX_RATE_MCS_SGI_MSK;
- } else if ((sco == IEEE80211_HTOP0_SCO_SCA ||
+ } else if ((sco == IEEE80211_HTOP0_SCO_SCA ||
sco == IEEE80211_HTOP0_SCO_SCB) &&
in->in_phyctxt != NULL && in->in_phyctxt->sco == sco) {
rate_flags |= IWX_RATE_MCS_CHAN_WIDTH_40;
@@ -7020,7 +7020,7 @@ iwx_rs_vht_rates(struct iwx_softc *sc, struct
ieee80211_node *ni, int num_ss)
/* Should not happen; Values above cover the possible range. */
panic("invalid VHT Rx MCS value %u", rx_mcs);
}
-
+
return ((1 << (max_mcs + 1)) - 1);
}
diff --git sys/net80211/ieee80211_node.c sys/net80211/ieee80211_node.c
index c874c874657..a6833e255ff 100644
--- sys/net80211/ieee80211_node.c
+++ sys/net80211/ieee80211_node.c
@@ -2458,7 +2458,7 @@ ieee80211_setup_vhtop(struct ieee80211_node *ni, const
uint8_t *data,
}
#ifndef IEEE80211_STA_ONLY
-/*
+/*
* Handle nodes switching from 11ac into legacy modes.
*/
void
diff --git sys/net80211/ieee80211_node.h sys/net80211/ieee80211_node.h
index e64e3ec26b2..a0c82378eb4 100644
--- sys/net80211/ieee80211_node.h
+++ sys/net80211/ieee80211_node.h
@@ -420,8 +420,8 @@ struct ieee80211_node {
#define IEEE80211_NODE_VHT 0x1 /* VHT negotiated */
#define IEEE80211_NODE_HTCAP 0x2 /* claims to support HT */
#define IEEE80211_NODE_VHTCAP 0x4 /* claims to support VHT */
-#define IEEE80211_NODE_VHT_SGI80 0x8 /* SGI on 80 MHz negotiated */
-#define IEEE80211_NODE_VHT_SGI160 0x10 /* SGI on 160 MHz negotiated
*/
+#define IEEE80211_NODE_VHT_SGI80 0x8 /* SGI on 80 MHz negotiated */
+#define IEEE80211_NODE_VHT_SGI160 0x10 /* SGI on 160 MHz negotiated */
/* If not NULL, this function gets called when ni_refcnt hits zero. */
void(*ni_unref_cb)(struct ieee80211com *,
@@ -516,7 +516,7 @@ ieee80211_node_supports_ht_chan40(struct ieee80211_node *ni)
(ni->ni_htop0 & IEEE80211_HTOP0_CHW));
}
-/*
+/*
* Check if the peer supports VHT.
initial iwx(4) 11ac patch for testing
This patch adds initial 11ac support to the iwx(4) driver.
This means that 80MHz channels can be used. No other 11ac features
are enabled yet.
This is not yet a patch which could be committed. Apart from debug
prints which need to go, there is a known issue found by dv@ where
this patch causes a firmware error, sysassert 0x20101A25. The reason
for this is not known.
It would help to get more testing to see if more clues can be found
based on where this error pops up. I cannot reproduce the error myself.
When sending feedback, please be clear about which iwx(4) device and
which access point has been tested. Thanks!
The patch works for me on AX200 and AX201 with a pepwave AC one mini AP,
although throughput is not much different to 11n 40MHz with this AP.
diff refs/heads/master refs/heads/11ac
blob - 57bdcce64458e7f9d5802ce4247d5651f9183200
blob + a56c59f82c854c282a61c302162df4eae3c27fb8
--- sys/dev/pci/if_iwx.c
+++ sys/dev/pci/if_iwx.c
@@ -304,6 +304,7 @@ int iwx_schedule_session_protection(struct iwx_softc *
uint32_t);
void iwx_init_channel_map(struct iwx_softc *, uint16_t *, uint32_t *, int);
void iwx_setup_ht_rates(struct iwx_softc *);
+void iwx_setup_vht_rates(struct iwx_softc *);
intiwx_mimo_enabled(struct iwx_softc *);
void iwx_mac_ctxt_task(void *);
void iwx_phy_ctxt_task(void *);
@@ -363,12 +364,13 @@ void iwx_clear_oactive(struct iwx_softc *, struct
iwx_
void iwx_rx_bmiss(struct iwx_softc *, struct iwx_rx_packet *,
struct iwx_rx_data *);
intiwx_binding_cmd(struct iwx_softc *, struct iwx_node *, uint32_t);
+uint8_tiwx_get_vht_ctrl_pos(struct ieee80211com *, struct
ieee80211_channel *);
intiwx_phy_ctxt_cmd_uhb_v3(struct iwx_softc *, struct iwx_phy_ctxt *,
uint8_t,
- uint8_t, uint32_t, uint8_t);
+ uint8_t, uint32_t, uint8_t, uint8_t);
intiwx_phy_ctxt_cmd_v3(struct iwx_softc *, struct iwx_phy_ctxt *, uint8_t,
- uint8_t, uint32_t, uint8_t);
+ uint8_t, uint32_t, uint8_t, uint8_t);
intiwx_phy_ctxt_cmd(struct iwx_softc *, struct iwx_phy_ctxt *, uint8_t,
- uint8_t, uint32_t, uint32_t, uint8_t);
+ uint8_t, uint32_t, uint32_t, uint8_t, uint8_t);
intiwx_send_cmd(struct iwx_softc *, struct iwx_host_cmd *);
intiwx_send_cmd_pdu(struct iwx_softc *, uint32_t, uint32_t, uint16_t,
const void *);
@@ -430,10 +432,12 @@ int iwx_scan_abort(struct iwx_softc *);
intiwx_enable_mgmt_queue(struct iwx_softc *);
intiwx_rs_rval2idx(uint8_t);
uint16_t iwx_rs_ht_rates(struct iwx_softc *, struct ieee80211_node *, int);
+uint16_t iwx_rs_vht_rates(struct iwx_softc *, struct ieee80211_node *, int);
intiwx_rs_init(struct iwx_softc *, struct iwx_node *);
intiwx_enable_data_tx_queues(struct iwx_softc *);
intiwx_phy_ctxt_update(struct iwx_softc *, struct iwx_phy_ctxt *,
- struct ieee80211_channel *, uint8_t, uint8_t, uint32_t, uint8_t);
+ struct ieee80211_channel *, uint8_t, uint8_t, uint32_t, uint8_t,
+ uint8_t);
intiwx_auth(struct iwx_softc *);
intiwx_deauth(struct iwx_softc *);
intiwx_run(struct iwx_softc *);
@@ -2812,6 +2816,15 @@ iwx_init_channel_map(struct iwx_softc *sc, uint16_t *c
if (ch_flags & IWX_NVM_CHANNEL_40MHZ)
channel->ic_flags |= IEEE80211_CHAN_40MHZ;
}
+
+ if (is_5ghz && data->sku_cap_11ac_enable) {
+ channel->ic_flags |= IEEE80211_CHAN_VHT;
+ if (ch_flags & IWX_NVM_CHANNEL_80MHZ) {
+ printf("%s: channel %d 80MHz ok\n", __func__,
hw_value);
+ channel->ic_xflags |= IEEE80211_CHANX_80MHZ;
+ } else
+ printf("%s: channel %d 80MHz NOT ok\n",
__func__, hw_value);
+ }
}
}
@@ -2846,6 +2859,34 @@ iwx_setup_ht_rates(struct iwx_softc *sc)
}
void
+iwx_setup_vht_rates(struct iwx_softc *sc)
+{
+ struct ieee80211com *ic = >sc_ic;
+ uint8_t rx_ant = iwx_fw_valid_rx_ant(sc);
+ int n;
+
+ ic->ic_vht_rxmcs = (IEEE80211_VHT_MCS_0_9 <<
+ IEEE80211_VHT_MCS_FOR_SS_SHIFT(1));
+
+ if (iwx_mimo_enabled(sc) &&
+ ((rx_ant & IWX_ANT_AB) == IWX_ANT_AB ||
+ (rx_ant & IWX_ANT_BC) == IWX_ANT_BC)) {
+ ic->ic_vht_rxmcs |= (IEEE80211_VHT_MCS_0_9 <<
+ IEEE80211_VHT_MCS_FOR_SS_SHIFT(2));
+ } else {
+ ic->ic_vht_rxmcs |= (IEEE80211_VHT_MCS_SS_NOT_SUPP <<
+ IEEE80211_VHT_MCS_FOR_SS_SHIFT(2));
+ }
+
+ for (n = 3; n <= IEEE80211_VHT_NUM_SS; n++) {
+ ic->ic_vht_rxmcs |= (IEEE80211_VHT_MCS_SS_NOT_SUPP <<
+ IEEE80211_VHT_MCS_FOR_SS_SHIFT(n));
+ }
+
+ ic->ic_vht_txmcs = ic->ic_vht_rxmcs;
+}
+
+void
iwx_init_reorder_buffer(struct iwx_reorder_buffer *reorder_buf,
Re: mg and trailing whitespaces
On Wed, Mar 02, 2022 at 09:47:31AM +0100, Omar Polo wrote: > Hello tech, > > mg(1) has this tendency to leave a lot of trailing whitespaces around in > auto-indent-mode and c-mode which I find annoying. Yes, there's > delete-trailing-space but it works only on the current line (and not the > whole buffer as in emacs) and one has to manually call it anyway. > Emacs, and even vi in base, are clever in this regard: trailing > whitespaces before the cursor are delete upon RET before adding a new > line. > > So, here's the same heuristic for mg when auto-indent-mode or c-mode is > enabled. It's still possible to leave trailing whitespace in a buffer > in those modes, it only gets a little bit harder to do. > > (as a next step I guess we could also garbage collect cc_strip_trailp, > it was used in only one place before this patch and is unconditionally > set to TRUE.) > > Thoughts/OK? I've tested the patch and it works as intended. I like new behavior for c-mode, but not sure if it is good for auto-indent one. If user presses and then I'd argue that removing first tab is good idea in this particular mode, but no hard objections, since I don't use auto-indent.
Re: ieee80211_stats userland vs. kernel
On Tue, Mar 08, 2022 at 02:38:39PM -0700, Theo de Raadt wrote: > Stefan Sperling wrote: > > In this case it is not ifconfig, but netstat -W iwm0. > > Which is a debugging tool, like netstat -s. > > We don't care when netstat breaks Alright, then this diff is indeed not necessary.
