Change Details

On this nice 8 core laptop I was having a heck of a time trying to get this driver to work. 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 /really/ 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. So I added some flushes - before a channel change, and during a transition to AUTH when the BSS config is being programmed into the firmware. This seems to have fixed it. Locally tested: * Wistron NuWeb AR5523 dual-band NIC, STA mode, 2/5GHz

uath: flush data/commands to the firmware before changing channel / state 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.

On this nice 8 core laptop I was having a heck of a time trying uath: flush data/commands to the firmware before changing channel / state to get this The driver to work. Iwasn'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 /really/ doesn't like a channel change 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. So I added some flushes - befor This acts like a channel change, and duringfence 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. This seems to have fixed it. Locally tested: * Wistron NuWeb AR5523 dual-band NIC, STA mode, 2/5GHz 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.