FWIW we would use iperf and push a lot of data to a STA and would cause lock ups and issues with the queues.


Craig


Craig Matsuura • Technical Director, Embedded Software Architecture

cmatsuura@vivint.com<mailto:cmatsuura@vivint.com> • P: 801.229.6005



simply smarter • vivint.com

3401 N Ashton Blvd. Lehi, UT 84043



[1497369905956_vivint-logo-orange.png]

________________________________
From: linux-wireless-owner@vger.kernel.org <redacted> on behalf of Stanislaw Gruszka <redacted>
Sent: Thursday, August 16, 2018 5:01:04 AM
To: Daniel Golle
Cc: Kofi Agor; Enrico Mioso; Craig Matsuura; Mathias Kresin; Tom Psyborg; linux-wireless; John Crispin; Felix Fietkau; Jamie Stuart
Subject: Re: ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue...?

Hello

On Thu, Aug 16, 2018 at 12:35:29AM +0200, Daniel Golle wrote:

quoted

Clone the master branch of
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.openwrt.org%2Fopenwrt%2Fstaging%2Fdangole.git&data=01%7C01%7Ccmatsuura%40vivint.com%7C259b5ae9949e445dd9fe08d603680486%7C54cc98ca024a470185483741e3b8d59d%7C0&sdata=8mOOSNRnqvjDVnCNHH15c%2BfEzr69yPpCkbSdD6Q8ZuA%3D&reserved=0
and give it shot and let us know the results.

Thanks!

quoted

quoted

Please also remove:
600-23-rt2x00-rt2800mmio-add-a-workaround-for-spurious-TX_F.patch
991-rt2800_change_rx_ampdu_factor.patch
992-rt2800_change_ba_size.patch
993-rt2800_change_rx_ampdu_density.patch
Those are not needed and can be harmful with the test patches,
(especially spurious interrupt one, patches will not apply cleanly
with it).

Ack. Hope it doesn't break Rt3883 and/or Rt3663 for which that patch
was added by Gabor Juhos a decade ago...

The new patches change the way we handle TX status interrupt. I think
spurious interrupts were a problem because we do not disable the IRQ
and read statuses, so we could get interrupt after we empty TX_STA_FIFO
register. With current implementation this should not be an issue.

quoted

quoted

Another thing is fixing RATE_PROBE frames which are aggregated with
other frames and not sent at requested rate. I implemented qsel queue patch
similar to mt76, but this not work as expected on older Ralink chips.
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsgruszka%2Fwireless-drivers-next%2Fcommit%2F846d205edd8c36d1b7828fee54bf4cf40bf8cb1a&data=01%7C01%7Ccmatsuura%40vivint.com%7C259b5ae9949e445dd9fe08d603680486%7C54cc98ca024a470185483741e3b8d59d%7C0&sdata=mI%2BPAh7OalmB1hxzjF%2FL6GqxwHDPi7Hy5P9IWADu5gI%3D&reserved=0

Which hardware did you try? Just so I can reproduce what's going on
and maybe help fixing it...

I tested on RT3062 PCI and some USB dongles, don't remember chip version.
Basically HW become unresponsive after sent some traffic.

I debugged the problem by printing sequence number and rate of RATE PROBE
frames by something like this:

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c b/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c
index 92ddc19..d7f250b 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c

@@ -334,6 +334,12 @@ static void rt2x00queue_create_tx_descriptor_ht(struct rt2x00_dev *rt2x00dev,
                         txdesc->u.ht.mcs |= 0x08;
         }

+       if (tx_info->flags & IEEE80211_TX_CTL_RATE_CTRL_PROBE) {
+               int ssn = le16_to_cpu(hdr->seq_ctrl) >> 4;
+               printk("RATE PROBE %d %d\n", ssn, txdesc->u.ht.mcs);
+       }
+
+
         if (test_bit(CONFIG_HT_DISABLED, &rt2x00dev->flags)) {
                 if (!(tx_info->flags & IEEE80211_TX_CTL_FIRST_FRAGMENT))
                         txdesc->u.ht.txop = TXOP_SIFS;

and compared that with on air traffic captured in monitor mode on
different device in wireshark. On air traffic showed different
probe frames rate than requested.

Regards
Stanislaw