And BTW, thank you to all of you involved on this, for the testing and the work 
involved. And all.

BTW - happy woman fest to all of you wimen, and the ones you know.

Enrico


On Wed, 7 Mar 2018, Jamie Stuart wrote:

Date: Wed, 7 Mar 2018 16:47:34
From: Jamie Stuart <ja...@onebillion.org>
To: Stanislaw Gruszka <sgrus...@redhat.com>
Cc: Daniel Golle <dan...@makrotopia.org>, Enrico Mioso <mrkiko...@gmail.com>,
    Tom Psyborg <pozega.tomis...@gmail.com>,
    linux-wireless <linux-wireless@vger.kernel.org>,
    Johannes Berg <johannes.b...@intel.com>, Arnd Bergmann <a...@arndb.de>,
    John Crispin <j...@phrozen.org>, Felix Fietkau <n...@nbd.name>,
    Mathias Kresin <d...@kresin.me>
Subject: Re: ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping
    frame due to full tx queue...?

Hi Stanis,

Our environment has the following wireless config (MT7620A):

config wifi-device 'radio0'
        option type 'mac80211'
        option channel 'auto'
        option hwmode '11g'
        option path 'platform/10180000.wmac'
        option txpower '20'
        option country 'GB'
        option htmode 'HT40'
        option noscan '1'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option encryption 'psk2+aes'
        option key ‘KEY'
        option maxassoc '96'
        option ssid ’SSID'
        option disassoc_low_ack ‘0'


The 30 clients are all Apple iPads (a mixture of iPad mini and mini 2, running 
iOS 9-11). During this testing period, all clients were simultaneously 
downloading files from the devices’ sdcard (served via nginx running on the 
device). Although this is not a typical use-case, it was useful in 
stress-testing the wireless setup.

We’ll try your patches Stanis.
Daniel - forgive the stupid question, but how do we apply Stanis’ patches atop 
your staging tree (or both yours and Stanis’ atop trunk?)



On 7 Mar 2018, at 14:27, Stanislaw Gruszka <sgrus...@redhat.com> wrote:

On Thu, Mar 01, 2018 at 04:30:10PM +0100, Daniel Golle wrote:
[forwarding to all other involved players]

On Thu, Mar 01, 2018 at 05:50:51PM +0300, Jamie Stuart wrote:
Hi Daniel,
The driver seems much improved after this fix.

it's about those two
[PATCH 1/2] rt2x00: pause almost full queue early
[PATCH 2/2] rt2x00: do not pause queue unconditionally on error path

Under very heavy load (30 clients downloading multi-GB files from SD card on 
the server concurrently), wifi dies with errors:

This is some testbed? Could you share how did you setup such
environment and what are client devices ?

[ 7794.230376] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame 
received with unrecognized signal, mode=0x0001, signal=0x010c, type=4

This is indicator that HW/FW has a problem. There could be various
reasons for that. One possible I can also observe in my setup,is strange
mishmash of seq  on frames which were not acked in BlockACK and
had to be resent. This can happen when many frames are wrongly decoded
(i.e. when there is bad radio condition or we have not correct low level
RF/BBP setup for a Ralink device). To mitigate that problem we can
limit length of agreggeted AMPDU frame.

I attached two patches which do that. One for RX side second for TX side.
Please check if they make a diffrent. You can also hardcode ba_size = 0
for those 30 clients setup.

Note the patches can cause (possibly small) perfromance degradation on
good setups.

Mathias, could you check them as well and see if they do not cause
performance regression on your device ? Lastly when I changed ba_size
setting, it was a problem on your setup.

Thu Mar  1 16:36:47 2018 kern.err kernel: [ 8702.146403] ieee80211 phy0: 
rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the non-full 
queue 2
Thu Mar  1 16:36:47 2018 kern.err kernel: [ 8702.146403] Please file bug report 
to http://rt2x00.serialmonkey.com
Thu Mar  1 16:36:48 2018 kern.err kernel: [ 8702.288149] ieee80211 phy0: 
rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the non-full 
queue 2
Thu Mar  1 16:36:48 2018 kern.err kernel: [ 8702.288149] Please file bug report 
to http://rt2x00.serialmonkey.com
Thu Mar  1 16:36:48 2018 kern.err kernel: [ 8702.380761] ieee80211 phy0: 
rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the non-full 
queue 2
Thu Mar  1 16:36:48 2018 kern.err kernel: [ 8702.380761] Please file bug report 
to http://rt2x00.serialmonkey.com

For those errors I recommend to remove

600-23-rt2x00-rt2800mmio-add-a-workaround-for-spurious-TX_F.patch

patch. Whould be good if OpenWRT developers could apply this patch only
on target where it is really needed, not for all rt2800 devices.

Thanks
Stanislaw

Reply via email to