On 2018-09-28 02:27, Rajkumar Manoharan wrote:

On 2018-09-28 00:51, Toke Høiland-Jørgensen wrote:

quoted

On 28 September 2018 07:29:03 CEST, Rajkumar Manoharan
[off-list ref] wrote:

quoted

On 2018-09-26 17:09, Rajkumar Manoharan wrote:

quoted

On 2018-09-26 02:22, Toke Høiland-Jørgensen wrote:

quoted

Rajkumar Manoharan [off-list ref] writes:

quoted

:( Yeah... I got confused with attached soft lockup in ARM platform.

Toke,

Cause for the soft lockup exposed in multi client scenario is due to
mixed order of fq_lock and active_txqs_lock. In wake_tx_queue or
push_pending
case, driver acquires active_txq_lock first by schedule_start and
followed by
fq_lock in tx_dequeue. The same order should be maintained in sta
cleanup.
Below change fixed the issue.

Ah, great find! I'll fold this into the next version, thanks!

One more thing. As I mentioned earlier, scheduling wake_txqs_tasklet
is heavy load and causing random rcu stall issue. Hence I added
another API to schedule throttled txqs once for all. Also I did
a cleanup in kick_airtime by traversing list only once. With these
changes I don't see rcu stall issue. Please review and fold them as 
well.

Correction in patch. new API schedule kick_aitime tasklet not 
wake_txq_tasklet.

+void ieee80211_txq_schedule_throttled(struct ieee80211_hw *hw)
+{
+       struct ieee80211_local *local = hw_to_local(hw);
+
+       tasklet_schedule(&local->kick_airtime);
+}

-Rajkumar