On 3/8/23 10:43, Dan Williams wrote:
On Wed, 2023-03-08 at 00:36 +0000, Ping-Ke Shih wrote:
I think NM triggers scan operation when turning it on. Then, driver
switches channels
between AP and scan channels with flushing queue that causes timeout.
The cause is
still hard to transmit packets out, so TX buffer gets jammed.
Yes, (at least historically) nm-applet requests that NM perform a scan
when you interact with it, on the theory that when you open the WiFi
network menu you probably want to see recent scan results. Similar to
MacOS's AirPort menu.
Most drivers handle that OK with intermittent traffic, but it will
cause disruption if for high throughput and/or latency-sensitive
traffic.
Dan
If you enlarge the retry count or timeout value of
__rtw_mac_flush_prio_queue(),
the timeout flushing could be disappear. Also, if we can implement
rtwdev->hci.ops->flush_queues for USB, the flushing log can be
reduced.
Dan: Thanks for confirming that a scan trigger was the likely cause of the
problem. I verified that by adding a WARN_ONCE() after the warning was printed.
The first part of the traceback was:
rtw_ops_flush
__ieee89211_flush_queues
ieee80211_offchannel_stop_vifs
__ieee80211_start_scan
__ieee80211_request_scan
rdev_scan
nl80211_trigger_scan
Ping-Ke: Increasing the time waiting for the queue to flush did not help. I
increased the loop count from 5 to 50, and the sleep time from 20 to 200 msec. I
also tested exiting as soon as "avail" was greater than zero. I also tested
unlocking the mutex before the msleep() and relocking it afterward. Nothing
changed the behavior. It appears that something else is locking the queue
clearing, and that no amount of delay will help.
I will be trying to write a USB version of the flush queues routine based on the
PCI code.
Sasha: I agree that no load is required to trigger the problem.
There are no simple problems!
Larry
