From: Enrico Mioso <mrkiko.rs@gmail.com>
To: Jamie Stuart <jamie@onebillion.org>
Cc: Stanislaw Gruszka <sgruszka@redhat.com>,
Daniel Golle <daniel@makrotopia.org>,
Tom Psyborg <pozega.tomislav@gmail.com>,
linux-wireless <linux-wireless@vger.kernel.org>,
Johannes Berg <johannes.berg@intel.com>,
Arnd Bergmann <arnd@arndb.de>, John Crispin <john@phrozen.org>,
Felix Fietkau <nbd@nbd.name>, Mathias Kresin <dev@kresin.me>
Subject: Re: ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue...?
Date: Thu, 8 Mar 2018 00:31:25 +0100 (CET) [thread overview]
Message-ID: <alpine.LNX.2.21.99.1803080030390.13982@mStation.localdomain> (raw)
In-Reply-To: <7B51BD3B-CAC3-479B-B06E-637A1C3A678A@onebillion.org>
[-- Attachment #1: Type: text/plain, Size: 4882 bytes --]
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 <jamie@onebillion.org>
> To: Stanislaw Gruszka <sgruszka@redhat.com>
> Cc: Daniel Golle <daniel@makrotopia.org>, Enrico Mioso <mrkiko.rs@gmail.com>,
> Tom Psyborg <pozega.tomislav@gmail.com>,
> linux-wireless <linux-wireless@vger.kernel.org>,
> Johannes Berg <johannes.berg@intel.com>, Arnd Bergmann <arnd@arndb.de>,
> John Crispin <john@phrozen.org>, Felix Fietkau <nbd@nbd.name>,
> Mathias Kresin <dev@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 <sgruszka@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
>
>
next prev parent reply other threads:[~2018-03-07 23:31 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-11 20:51 ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue...? Enrico Mioso
2017-12-13 15:20 ` Stanislaw Gruszka
2017-12-16 18:33 ` Enrico Mioso
2017-12-18 15:21 ` Stanislaw Gruszka
2017-12-19 12:27 ` Stanislaw Gruszka
2017-12-19 12:39 ` Enrico Mioso
2017-12-19 12:43 ` Enrico Mioso
2017-12-19 12:54 ` Stanislaw Gruszka
2017-12-19 13:25 ` Enrico Mioso
2017-12-20 17:49 ` Enrico Mioso
2017-12-21 14:25 ` Stanislaw Gruszka
2017-12-24 12:19 ` Enrico Mioso
2018-01-03 11:35 ` Stanislaw Gruszka
2018-01-03 14:04 ` Enrico Mioso
[not found] ` <CAKR_QVLRwAA0NJSarX46J4A8XSp8h5SuTEtSBQ4ydpEPh_-aUw@mail.gmail.com>
2018-01-22 5:45 ` Enrico Mioso
2018-01-23 13:22 ` Stanislaw Gruszka
2018-01-24 5:14 ` Enrico Mioso
2018-01-24 8:18 ` Enrico Mioso
2018-01-24 10:03 ` Stanislaw Gruszka
2018-03-01 15:30 ` Daniel Golle
2018-03-02 19:13 ` Enrico Mioso
2018-03-07 12:27 ` Stanislaw Gruszka
2018-03-07 12:29 ` Stanislaw Gruszka
2018-03-23 7:51 ` Mathias Kresin
2018-03-26 10:35 ` Stanislaw Gruszka
2018-03-27 7:46 ` Mathias Kresin
2018-03-27 17:18 ` Stanislaw Gruszka
2018-03-27 17:43 ` Daniel Golle
2018-03-28 4:14 ` Enrico Mioso
[not found] ` <CAOt++SeSQ2j1KuVkbqt77LfznXN7JV0Lx5O8d7-m2VBrz8=85g@mail.gmail.com>
2018-03-29 5:13 ` Enrico Mioso
2018-03-30 14:41 ` Enrico Mioso
2018-03-30 14:44 ` Enrico Mioso
[not found] ` <MWHPR02MB3326233159B021143D7278F5D4A10@MWHPR02MB3326.namprd02.prod.outlook.com>
2018-03-30 17:33 ` Enrico Mioso
[not found] ` <CAOt++SeLh_NxcmM=YEMQSv4y9PabS_dT7k4yTxUiqXbac-=iUQ@mail.gmail.com>
2018-04-17 13:55 ` Enrico Mioso
2018-04-17 13:56 ` Jamie Stuart
2018-04-17 13:57 ` Enrico Mioso
2018-04-17 19:42 ` Stanislaw Gruszka
[not found] ` <CAOt++SeNt=4RUTvAR1y_WjC=a-YyYa3YBSmoAmv+7uK71U+3+A@mail.gmail.com>
2018-05-28 12:50 ` Stanislaw Gruszka
2018-05-28 13:54 ` Daniel Golle
2018-08-15 11:40 ` Stanislaw Gruszka
2018-08-15 22:35 ` Daniel Golle
2018-08-16 11:01 ` Stanislaw Gruszka
[not found] ` <DM5PR02MB365669D5E9F2DE20DAE4CB7AD43E0@DM5PR02MB3656.namprd02.prod.outlook.com>
2018-08-18 16:08 ` Daniel Golle
2018-08-20 12:20 ` Stanislaw Gruszka
2018-08-24 13:02 ` Stanislaw Gruszka
2018-03-28 18:13 ` Stanislaw Gruszka
2018-03-07 15:47 ` Jamie Stuart
2018-03-07 23:30 ` Enrico Mioso
2018-03-07 23:31 ` Enrico Mioso [this message]
2018-03-08 9:39 ` Stanislaw Gruszka
2018-03-08 14:28 ` Enrico Mioso
2018-01-23 13:20 ` Stanislaw Gruszka
2017-12-26 17:20 ` Enrico Mioso
2018-01-03 11:45 ` Stanislaw Gruszka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LNX.2.21.99.1803080030390.13982@mStation.localdomain \
--to=mrkiko.rs@gmail.com \
--cc=arnd@arndb.de \
--cc=daniel@makrotopia.org \
--cc=dev@kresin.me \
--cc=jamie@onebillion.org \
--cc=johannes.berg@intel.com \
--cc=john@phrozen.org \
--cc=linux-wireless@vger.kernel.org \
--cc=nbd@nbd.name \
--cc=pozega.tomislav@gmail.com \
--cc=sgruszka@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).