yuweizheng@139.com

=0A

= From: Felix Fietkau
<= div>Date: 2015-02-19 16:09
To: Yuwei Zheng; linux-kernel; ath9k-devel; linux-wireless; kvalo= ; ath9k-devel
CC: netdev= ; zhengyuwei
Subject= : Re: [PATCHv2] ath9k_htc: add adaptive usb receive flow control = to repair soft lockup with monitor mode
On 2015= -02-10 11:34, Yuwei Zheng wrote:
=0A
> The ath9k_hif_usb_rx_cb= function excute on the interrupt context, and ath9k_rx_tasklet excu= te
=0A
> on the soft irq context. In other words, the ath9k_hi= f_usb_rx_cb have more chance to excute than
=0A
> ath9k_rx_tas= klet. So in the worst condition, the rx.rxbuf receive list is = always full,
=0A
> and the do {}while(true) loop will not be b= reak. The kernel get a soft lockup panic.
=0A
>
= =0A
> [59011.007210] BUG: soft lockup - CPU#0 stuck for 23s!
= =0A
> [kworker/0:0:30609]
=0A
> [59011.030560] BUG: sch= eduling while atomic: kworker/0:0/30609/0x40010100
=0A
> [5901= 3.804486] BUG: scheduling while atomic: kworker/0:0/30609/0x40010100
= =0A
> [59013.858522] Kernel panic - not syncing: softlockup: hung t= asks
=0A
>
=0A
> [59014.038891] Exception s= tack(0xdf4bbc38 to 0xdf4bbc80)
=0A
> [59014.046834] bc20: = ; &= nbsp; &nb= sp; = ; &= nbsp; de57b950 60000113
=0A
> [59014.059579]= bc40: 00000000 bb32bb32 60000113 de57b948 de57b500 dc7bb440 df4bbcd0 0000= 0000
=0A
> [59014.072337] bc60: de57b950 60000113 df4bbcd0 df4= bbc80 c04c259d c04c25a0 60000133 ffffffff
=0A
> [59014.085233]= [<c04c28db>] (__irq_svc+0x3b/0x5c) from [<c04c25a0>] (_raw_sp= in_unlock_irqrestore+0xc/0x10)
=0A
> [59014.100437] [<c04c2= 5a0>] (_raw_spin_unlock_irqrestore+0xc/0x10) from [<bf9c2089>] (a= th9k_rx_tasklet+0x290/0x490 [ath9k_htc])
=0A
> [59014.118267] = [<bf9c2089>] (ath9k_rx_tasklet+0x290/0x490 [ath9k_htc]) from [<c0= 036d23>] (tasklet_action+0x3b/0x98)
=0A
> [59014.134132] [&= lt;c0036d23>] (tasklet_action+0x3b/0x98) from [<c0036709>] (__do_= softirq+0x99/0x16c)
=0A
> [59014.147784] [<c0036709>] (_= _do_softirq+0x99/0x16c) from [<c00369f7>] (irq_exit+0x5b/0x5c)
= =0A
> [59014.160653] [<c00369f7>] (irq_exit+0x5b/0x5c) from [= <c000cfc3>] (handle_IRQ+0x37/0x78)
=0A
> [59014.173124] = [<c000cfc3>] (handle_IRQ+0x37/0x78) from [<c00085df>] (omap3_i= ntc_handle_irq+0x5f/0x68)
=0A
> [59014.187225] [<c00085df&g= t;] (omap3_intc_handle_irq+0x5f/0x68) from [<c04c28db>](__irq_svc+0x= 3b/0x5c)
=0A
>
=0A
> This bug can be see wi= th low performance board, such as uniprocessor beagle bone board. Add some= debug
=0A
> message in the ath9k_hif_usb_rx_cb function may = trigger this bug quickly.
=0A
>
=0A
> Signe= d-off-by: Yuwei Zheng <yuweizheng@139.com>
=0A
This approac= h of interaction between tasklet and workqueue processing
=0A
see= ms quite complex to me. Wouldn't it be simpler and better to simply
= =0A
always run the rx processing code in workqueue context?
=0AThat way it can go on processing forever (as long as there is data to b= e
=0A
received), while the scheduler ensures that it doesn't inte= rfere with
=0A
other critical work on the CPU.
=0A
= ;
=0A
- Felix
=0A