[rt2x00-users] [PATCH 3.3] rt2x00: fix random stalls
sgruszka at redhat.com
Thu Mar 8 05:46:36 EST 2012
On Tue, Mar 06, 2012 at 06:43:56PM +0100, Martin Hundebøll wrote:
> On 03/05/2012 05:48 PM, Stanislaw Gruszka wrote:
> >Is possible that we stop queue and then do not wake up it again,
> >especially when packets are transmitted fast. That can be easily
> >reproduced with modified tx queue entry_num to some small value e.g. 16.
> >If mac80211 already hold local->queue_stop_reason_lock, then we can wait
> >on that lock in both rt2x00queue_pause_queue() and
> >rt2x00queue_unpause_queue(). After drooping ->queue_stop_reason_lock
> >is possible that __ieee80211_wake_queue() will be performed before
> >__ieee80211_stop_queue(), hence we stop queue and newer wake up it
> >To prevent stalls serialize pause/unpause by queue->tx_lock.
> I've been having CPU load issues with rt2800usb/Ralink RT2870, when doing simultaneous TX/RX between to nodes in an adhoc network. While transfering UDP packets in one direction with iperf, I get ~23Mbit/s and kworker is utilizing <10% of the CPU (OMAP4 1GHz dualcore or/and Pentium M 1.70GHz) on both ends. When doing bidirectional tests with iperf, one kworker thread jumps too 100% and throughput drops.
> By using two iperf clients to do bidirectional TCP transfers, I got ~6Mbit/s in both directions, so I suspected some queueing issues and thus applied this patch, but no change. I've tried to do some tracing, but this is quite new to me, so please instruct me, if you need more info.
I did short test here and do not enter that issue. Which kernel version are you using?
> out.txt has a trace from 10.10.10.55 while running iperf as in  and the following commands:
Please newer do this again :-) If you want to provide such big data, put it
somewhere and paste download link to the email. Moreover that tracing
did not provide any useful information.
More information about the users