Re: [PATCH 3.3] rt2x00: fix random stalls

["Martin Hundebøll" <m.hundeboll@gmail.com>]

Hi,

On 03/07/2012 07:46 PM, Stanislaw Gruszka wrote:
> Hi
>
> On Tue, Mar 06, 2012 at 06:43:56PM +0100, Martin Hundebøll wrote:
>> Hi,
>>
>> 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
>>> again.
>>>
>>> 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[1], 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[2], 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[3], 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?

I forgot to mention, that we work with adhoc networks. I've tested 2.6.38.4 and 3.2.7, with in-tree and compat-wireless on both versions.

However, the issue is fixed by another patch-set posted on users@rt2x00.serialmonkey.com ([RFC/RFT 0/5] rt2x00: rt2800usb: rework tx path). So now I "just" see random stalls, which should be fixed by this patch. (I will test the most recent version shortly.)

>> [3]
>> out.txt has a trace from 10.10.10.55 while running iperf as in [2] 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.

Will never happen again :)

// Martin