The driver wasn't stable - it would start fine, but during scan
it would eventually hang and no further command endpoint transfers
would complete.
After adding some debugging and looking at the logs I noticed that
things went sideways once a /data/ frame was sent. The channel
change config happened between the data frame being sent and
being completed.
My guess is that the firmware doesn't like a channel change
and reset whilst there's pending data frames. Checking the Linux
driver I found that it was doing a flush before a channel change,
and we're doing it afterwards. This acts like a fence around
ensuring scheduled TX work has completed. In net80211 the
transmit path and the control path aren't serialised, so it's
very often the case that ioctls, state changes, etc occur
whilst in parallel there are frame transmits being scheduled.
This seems to happen more frequently on a more recent, high core
(8) machine with XHCI. I remember testing this driver years ago
on single and dual core CPU laptops with no problems.
So, add some flushes - before a channel change, and during
a transition to AUTH when the BSS config is being programmed into
the firmware. These two fences seem enough to reliably
associate as a 2GHz and 5GHz STA.
Note that this isn't entirely blocking all newly queued
transmit work from occuring until after the NIC has finished
configuration. That will need some further investigation.
Locally tested:
* Wistron NuWeb AR5523 dual-band NIC, STA mode, 2/5GHz
Differential Revision: https://reviews.freebsd.org/D47655
842a2c1ad3