Hello

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

Clone the master branch of
https://git.openwrt.org/openwrt/staging/dangole.git
and give it shot and let us know the results.

Thanks!

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

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://github.com/sgruszka/wireless-drivers-next/commit/846d205edd8c36d1b7828fee54bf4cf40bf8cb1a

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