Still seeing a lot of those Sat Aug 18 16:05:51 2018 kern.err kernel: [ 8364.972151] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 Sat Aug 18 16:05:51 2018 kern.err kernel: [ 8364.981622] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 Sat Aug 18 16:05:51 2018 kern.err kernel: [ 8364.991070] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 Sat Aug 18 16:05:51 2018 kern.err kernel: [ 8365.000506] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 Sat Aug 18 16:05:51 2018 kern.err kernel: [ 8365.009935] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 while wifi somehow keeps working at degraded level once the error occured. On Thu, Aug 16, 2018 at 07:30:40PM +0000, Craig Matsuura wrote: > 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@xxxxxxxxxx<mailto:cmatsuura@xxxxxxxxxx> • P: 801.229.6005 > > > > simply smarter • vivint.com > > 3401 N Ashton Blvd. Lehi, UT 84043 > > > > [1497369905956_vivint-logo-orange.png] > > ________________________________ > From: linux-wireless-owner@xxxxxxxxxxxxxxx <linux-wireless-owner@xxxxxxxxxxxxxxx> on behalf of Stanislaw Gruszka <sgruszka@xxxxxxxxxx> > 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: > > 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! > > > > 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. > > > > 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
