Bug 193481

Those messages mean that device fail to write to particualr register i.e. 0x1020 via USB bus, -110 is -ETIMEDOUT error, what mean USB transfaer fail to happen in reasonable time.

This could be rt2800 driver/firmware/hardware issue or USB host driver/fw/hw issue, hard to tell. If they does not couse any malfunction I would ignore them.

I can see you have also:

Jan 28 10:31:09.468739 myasrocke350m1 kernel: ieee80211 phy0: rt2800usb_txdone: Warning - Data pending for entry 13 in queue 2

This should be mittigated in 4.10 and possibly fixed in 4.11 .

I'm having the "Data pending for entry ..." warning and severe wifi performance problems after upgrading from a 4.7 series kernel to 4.15. Can you point to the changes in 4.10/4.11 that were supposed to have improved/fixed this in case they suggest a cause for the regression?

Rich, what hardware do you have ? Could you narrow regression into two constitutive kernel versions ?

It's the Alfa AWUS036NH. I can't narrow the regression with the box it's actually used on since I need it up and running. I use it as an access point with hostapd. Oddly, moving to channel 11 (from 6) seems to have made the problem go away, so I'm just doing that for now.

I do have an extra identical wifi adapter and might be able to reproduce the issue on another box and bisect it.

FYI I tried aplying 3d8f162cb8 and 6dd80efd75 from Linus's tree since they looked related, but they did not seem to make any difference. I do still have them applied now with the kernel that's working on channel 11.

One other piece of information: the driver had never previously used 40 MHz wide channels, only 20 MHz; after upgrading I found it using 40 MHz. But changing hostapd.conf to disable that didn't seem to help when it as at channel 6. I'd had it work fine with both narrow and wide on channel 11. This might be related, since the driver or the hardware actually refuses to configure channel 1 (and possibly other low channels). The wide channel at 6 would extend down to 1 the hardware or driver might be refusing to actually tx/rx in that band..?

It is possible that there is bigger radio contention on channels 1 - 6 . You can check for wifi contention by "iw dev wlan0 scan | egrep "primary channel" | sort | uniq -c",  but it will not show other radios like Bluetooth.

I assume you downgraded to 4.7 and confirmed it works flawlessly on channel 6, correct ?

I looked for RT3070 (your alfa device) specific changes. 66ecec02e8 looks suspicious, perhaps we should not increase max_psdu on RT3070. You can check to revert this commit and see if it makes things better on channel 6.

Yes, I downgraded (just moved the old vmlinuz back in place, using extlinux) and the problem went away (on channel 6). But the reason I was upgrading is because my 4.7 build was not suitable for the new hardware I swapped the drive to, so now that the move-over is complete I can't easily test it further without setting up another test box.

I'll rebuild 4.15 with 66ecec02e8 reverted and let you know how it goes after next reboot (might not be right away). Reading the commit it looks somewhat promising.

Some further updates:

Even moving to channel 11 where I didn't get any errors in syslog, I've had a lot of problems with packet loss and major latency coming and going since switching to Linux 4.15.

With 66ecec02e8 reverted, it seems to be okay. At first I still got the "Data pending for entry" warnings and severe performance problems with hostapd using wide channels (which never got enabled with old kernel), but when I disabled that feature, everything seems to be working fine on channel 6 or channel 11. No warnings in syslog and ping is consistently 1.9-2.5 ms rather than dropping or shooting up into the hundreds or even >2000 every few minutes.

Rich,

so with HT20 it things worked as before ? On HT40 there are problems, but on 4.7 this was not tested, right?

Not sure if I'll revert 66ecec02e8 in the kernel, perhaps I'll prepare fix that still use max_psdu=3 on newer devices.

Please provide part from dmesg with RT/RF chipset and revision version, so I would know what exact device do you have.

Yes, things seem to work as before with HT20, and HT40 was untested (never selected by driver or hostapd, whichever is responsible) on 4.7. I haven't had any further serious latency or packet loss problems. I have had some minor one-direction ping spikes still (B pinging A is uniformly low, A pinging B jumps around, A is access point) that I don't recall seeing before but it doesn't seem to affect any actual traffic except ICMP and since it's just one direction I'm assuming it must have something to do with kernel/scheduling behavior rather than network device.

Here are the relevant dmesg lines:

[   67.748078] usb 1-2: new high-speed USB device number 7 using xhci_hcd
[   67.894944] usb 1-2: New USB device found, idVendor=148f, idProduct=3070
[   67.894958] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   67.894968] usb 1-2: Product: 802.11 n WLAN
[   67.894977] usb 1-2: Manufacturer: Ralink
[   67.894986] usb 1-2: SerialNumber: 1.0
[   68.015799] usb 1-2: reset high-speed USB device number 7 using xhci_hcd
[   68.158191] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 3070, rev 0201 detected
[   68.243170] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0005 detected
[   68.244363] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[   69.057694] ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin'
[   69.060180] ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.36

The "Data pending for entry ..." messages have come back. :( And I've seen some on channel 11 too.

I posted revert of another commit:
https://marc.info/?l=linux-wireless&m=152750671715369&w=2

You can give it a try, perhaps it helps even without revert of 66ecec02e8.