Bug 193481 - rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x131c with error -110
Summary: rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x131...
Status: CLOSED OBSOLETE
Alias: None
Product: Drivers
Classification: Unclassified
Component: network-wireless (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_network-wireless@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-01-28 17:27 UTC by Paul Menzel
Modified: 2019-07-11 07:44 UTC (History)
2 users (show)

See Also:
Kernel Version: 4.9.2
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Paul Menzel 2017-01-28 17:27:43 UTC
With Linux 4.9.2 from Debian Sid/unstable, Linux reports two errors form my WLAN USB device.


```
$ more /proc/version
Linux version 4.9.0-1-686-pae (debian-kernel@lists.debian.org) (gcc version 6.3.0 20161229 (Debian 6.3.0-2) ) #1 SMP Debian 4.9.2-2 (2017-01-12)
$ lsusb
[…]
Bus 001 Device 004: ID 148f:2870 Ralink Technology, Corp. RT2870 Wireless Adapter
[…]
$ journalctl -b | grep rt2x00
[…]
Jan 28 09:33:42.618259 myasrocke350m1 kernel: ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 2872, rev 0202 detected
Jan 28 09:33:42.669014 myasrocke350m1 kernel: ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0001 detected
Jan 28 09:33:42.768851 myasrocke350m1 kernel: ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
Jan 28 09:34:09.591647 myasrocke350m1 NetworkManager[815]: <info>  [1485592449.5915] rfkill0: found WiFi radio killswitch (at /sys/devices/pci0000:00/0000:00:12.2/usb1/1-3
Jan 28 09:34:22.840918 myasrocke350m1 kernel: ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin'
Jan 28 09:34:22.933266 myasrocke350m1 kernel: ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.36
Jan 28 10:05:55.671495 myasrocke350m1 kernel: ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x131c with error -110
Jan 28 10:06:37.999939 myasrocke350m1 kernel: ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x1020 with error -110
Jan 28 10:31:09.468739 myasrocke350m1 kernel: ieee80211 phy0: rt2800usb_txdone: Warning - Data pending for entry 13 in queue 2
Jan 28 17:35:35.388006 myasrocke350m1 kernel: ieee80211 phy1: rt2x00_set_rt: Info - RT chipset 2872, rev 0202 detected
Jan 28 17:35:35.431205 myasrocke350m1 kernel: ieee80211 phy1: rt2x00_set_rf: Info - RF chipset 0001 detected
Jan 28 17:35:35.432062 myasrocke350m1 kernel: ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
Jan 28 17:35:35.432854 myasrocke350m1 kernel: ieee80211 phy1: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin'
Jan 28 17:35:35.492057 myasrocke350m1 kernel: ieee80211 phy1: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.36
```

Can something be done to address that error? Is there documentation what that error is about and what the consequences are?
Comment 1 Stanislaw Gruszka 2017-02-18 12:51:20 UTC
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.
Comment 2 Stanislaw Gruszka 2017-02-18 12:53:47 UTC
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 .
Comment 3 Rich Felker 2018-02-20 00:58:05 UTC
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?
Comment 4 Stanislaw Gruszka 2018-02-20 08:03:44 UTC
Rich, what hardware do you have ? Could you narrow regression into two constitutive kernel versions ?
Comment 5 Rich Felker 2018-02-20 17:41:44 UTC
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..?
Comment 6 Stanislaw Gruszka 2018-02-21 08:53:30 UTC
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.
Comment 7 Rich Felker 2018-02-21 16:06:22 UTC
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.
Comment 8 Rich Felker 2018-04-02 23:47:29 UTC
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.
Comment 9 Stanislaw Gruszka 2018-04-06 11:20:59 UTC
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.
Comment 10 Rich Felker 2018-04-06 15:10:02 UTC
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
Comment 11 Rich Felker 2018-04-27 00:16:23 UTC
The "Data pending for entry ..." messages have come back. :( And I've seen some on channel 11 too.
Comment 12 Stanislaw Gruszka 2018-06-06 15:40:50 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.