On 2018-09-28 02:27, Rajkumar Manoharan wrote:
On 2018-09-28 00:51, Toke Høiland-Jørgensen wrote:
On 28 September 2018 07:29:03 CEST, Rajkumar Manoharan
<rmanohar@xxxxxxxxxxxxxx> wrote:
On 2018-09-26 17:09, Rajkumar Manoharan wrote:
On 2018-09-26 02:22, Toke Høiland-Jørgensen wrote:
Rajkumar Manoharan <rmanohar@xxxxxxxxxxxxxx> writes:
:( 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
