Re: [PATCH] ath9k_htc: add adaptive usb flow control to repair soft lockup with monitor mode

yuweizheng@139.com writes:

From: Yuwei Zheng <redacted>

In the environment with heavy wifi traffic, set the ar9271 into monitor mode, will
trigger a deadloop panic.
 
The ath9k_hif_usb_rx_cb function excute on  the interrupt context, and ath9k_rx_tasklet excute
on the soft irq context. In other words, the ath9k_hif_usb_rx_cb have more chance to excute than
ath9k_rx_tasklet.  So in the worst condition,  the rx.rxbuf receive list is always full,
and the do {}while(true) loop will not be break. The kernel get a soft lockup panic. 

The word wrapping is still wrong, please limit the width to 72 chars or
so. But no need to wrap log snippets, they can exceed the limit.

Signed-off-by: Yuwei Zheng <redacted>
Signed-off-by: Yuwei Zheng <redacted>

Why two of these? Please use just one Signed-off-by line. Unless these
are two different persons with the same name :)

-- 
Kalle Valo

It seems to work without noticeable regressions.

Am 03.02.2015 um 12:52 schrieb Kalle Valo:

yuweizheng-7R9yAhoRP9E@public.gmane.org writes:

quoted

From: Yuwei Zheng <redacted>

In the environment with heavy wifi traffic, set the ar9271 into monitor mode, will
trigger a deadloop panic.
 
The ath9k_hif_usb_rx_cb function excute on  the interrupt context, and ath9k_rx_tasklet excute
on the soft irq context. In other words, the ath9k_hif_usb_rx_cb have more chance to excute than
ath9k_rx_tasklet.  So in the worst condition,  the rx.rxbuf receive list is always full,
and the do {}while(true) loop will not be break. The kernel get a soft lockup panic. 

The word wrapping is still wrong, please limit the width to 72 chars or
so. But no need to wrap log snippets, they can exceed the limit.

quoted

Signed-off-by: Yuwei Zheng <redacted>
Signed-off-by: Yuwei Zheng <redacted>

Why two of these? Please use just one Signed-off-by line. Unless these
are two different persons with the same name :)

-- 
Regards,
Oleksij