* rt2x00 regression @ 2019-09-26 16:32 Anton Olsson 2019-09-27 8:03 ` Stanislaw Gruszka 0 siblings, 1 reply; 20+ messages in thread From: Anton Olsson @ 2019-09-26 16:32 UTC (permalink / raw) To: linux-wireless; +Cc: Stanislaw Gruszka, Helmut Schaa Hello I have a USB based ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070 Wireless Adapter, that stops working with recent kernels. It works on kernel 5.1.15 and does not work with 5.2.7 or 5.3.1 (I have not tested other versions). I use it in AP mode. I found this similar bug report https://marc.info/?l=linux-wireless&m=156630037103575&w=2 but that did not have related error messages so I assume this is different? Logs of working kernel 5.1.15-arch1-1-ARCH. [ 78.680555] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 3070, rev 0201 detected [ 78.690992] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0005 detected [ 78.799625] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' sep 26 17:13:03 kernel: usbcore: registered new interface driver rt2800usb sep 26 17:13:03 systemd[1]: Found device RT2870/RT3070 Wireless Adapter. [ 113.812454] ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin' [ 113.905279] ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.36 [ 114.028703] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x0404 with error -71 The last error there does not seem to affect the operation of the device. Logs of not working with kernel 5.3.1, 5.2.7 has similar output. sep 26 17:06:12 kernel: ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 3070, rev 0201 detected sep 26 17:06:12 kernel: ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0005 detected sep 26 17:06:12 kernel: ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' sep 26 17:06:12 kernel: usbcore: registered new interface driver rt2800usb sep 26 17:06:12 systemd[1]: Found device RT2870/RT3070 Wireless Adapter. sep 26 17:06:21 ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin' sep 26 17:06:21 ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.36 sep 26 17:06:21 ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x0404 with> sep 26 17:06:22 ieee80211 phy0: rt2800_wait_csr_ready: Error - Unstable hardware sep 26 17:06:22 ieee80211 phy0: rt2800usb_set_device_state: Error - Device failed to enter state 4 (-5) Unable to bring up the network interface here. Tell me if you want me to run any commands or test any patches. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: rt2x00 regression 2019-09-26 16:32 rt2x00 regression Anton Olsson @ 2019-09-27 8:03 ` Stanislaw Gruszka [not found] ` <CA+GwT0B5SyRZnGLqwqOeuJK4CWMVc=dKaWre9VN8KQC6kBzKGw@mail.gmail.com> 0 siblings, 1 reply; 20+ messages in thread From: Stanislaw Gruszka @ 2019-09-27 8:03 UTC (permalink / raw) To: Anton Olsson; +Cc: linux-wireless, Helmut Schaa On Thu, Sep 26, 2019 at 06:32:23PM +0200, Anton Olsson wrote: > Hello I have a USB based ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070 Wireless Adapter, that stops working with recent kernels. It works on kernel 5.1.15 and does not work with 5.2.7 or 5.3.1 (I have not tested other versions). I use it in AP mode. > > I found this similar bug report https://marc.info/?l=linux-wireless&m=156630037103575&w=2 but that did not have related error messages so I assume this is different? > > Logs of working kernel 5.1.15-arch1-1-ARCH. > [ 78.680555] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 3070, rev 0201 detected > [ 78.690992] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0005 detected > [ 78.799625] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' > sep 26 17:13:03 kernel: usbcore: registered new interface driver rt2800usb > sep 26 17:13:03 systemd[1]: Found device RT2870/RT3070 Wireless Adapter. > [ 113.812454] ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin' > [ 113.905279] ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.36 > [ 114.028703] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x0404 with error -71 > > The last error there does not seem to affect the operation of the device. > > Logs of not working with kernel 5.3.1, 5.2.7 has similar output. > sep 26 17:06:12 kernel: ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 3070, rev 0201 detected > sep 26 17:06:12 kernel: ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0005 detected > sep 26 17:06:12 kernel: ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' > sep 26 17:06:12 kernel: usbcore: registered new interface driver rt2800usb > sep 26 17:06:12 systemd[1]: Found device RT2870/RT3070 Wireless Adapter. > sep 26 17:06:21 ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin' > sep 26 17:06:21 ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.36 > sep 26 17:06:21 ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x0404 with> > sep 26 17:06:22 ieee80211 phy0: rt2800_wait_csr_ready: Error - Unstable hardware > sep 26 17:06:22 ieee80211 phy0: rt2800usb_set_device_state: Error - Device failed to enter state 4 (-5) > > Unable to bring up the network interface here. This most likely is the problem introduced by commit: commit e383c70474db32b9d4a3de6dfbd08784d19e6751 Author: Stanislaw Gruszka <sgruszka@redhat.com> Date: Tue Mar 12 10:51:42 2019 +0100 rt2x00: check number of EPROTO errors Plase check below patch that increase number of EPROTO checks before marking device removed. If it does not help, plese check if reverting above commits helps. diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c index bc2dfef0de22..215c3f092306 100644 --- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c @@ -30,7 +30,7 @@ static bool rt2x00usb_check_usb_error(struct rt2x00_dev *rt2x00dev, int status) else rt2x00dev->num_proto_errs = 0; - if (rt2x00dev->num_proto_errs > 3) + if (rt2x00dev->num_proto_errs > 8) return true; return false; ^ permalink raw reply related [flat|nested] 20+ messages in thread
[parent not found: <CA+GwT0B5SyRZnGLqwqOeuJK4CWMVc=dKaWre9VN8KQC6kBzKGw@mail.gmail.com>]
* Re: rt2x00 regression [not found] ` <CA+GwT0B5SyRZnGLqwqOeuJK4CWMVc=dKaWre9VN8KQC6kBzKGw@mail.gmail.com> @ 2019-12-03 7:57 ` Stanislaw Gruszka 2019-12-03 18:50 ` Anton Olsson 0 siblings, 1 reply; 20+ messages in thread From: Stanislaw Gruszka @ 2019-12-03 7:57 UTC (permalink / raw) To: Exuvo; +Cc: linux-wireless, Helmut Schaa On Mon, Dec 02, 2019 at 05:40:20PM +0100, Exuvo wrote: > Sorry for the late reply > > The patch for increasing the amount did not work, i'll get around to > testing with the commit reverted. So, revert of that commit makes the problem gone ? > As an aside what function can i call at that point in the code to print the > value in num_proto_errs? I assume some kernel special printf? It's printk. You can add line like this to print values: printk("status %d num_proto_errs %u\n", status, rt2x00dev->num_proto_errs); Stanislaw > On Fri, 27 Sep 2019, 10:03 Stanislaw Gruszka, <sgruszka@redhat.com> wrote: > > > On Thu, Sep 26, 2019 at 06:32:23PM +0200, Anton Olsson wrote: > > > Hello I have a USB based ID 148f:3070 Ralink Technology, Corp. > > RT2870/RT3070 Wireless Adapter, that stops working with recent kernels. It > > works on kernel 5.1.15 and does not work with 5.2.7 or 5.3.1 (I have not > > tested other versions). I use it in AP mode. > > > > > > I found this similar bug report > > https://marc.info/?l=linux-wireless&m=156630037103575&w=2 but that did > > not have related error messages so I assume this is different? > > > > > > Logs of working kernel 5.1.15-arch1-1-ARCH. > > > [ 78.680555] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 3070, > > rev 0201 detected > > > [ 78.690992] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0005 > > detected > > > [ 78.799625] ieee80211 phy0: Selected rate control algorithm > > 'minstrel_ht' > > > sep 26 17:13:03 kernel: usbcore: registered new interface driver > > rt2800usb > > > sep 26 17:13:03 systemd[1]: Found device RT2870/RT3070 Wireless Adapter. > > > [ 113.812454] ieee80211 phy0: rt2x00lib_request_firmware: Info - > > Loading firmware file 'rt2870.bin' > > > [ 113.905279] ieee80211 phy0: rt2x00lib_request_firmware: Info - > > Firmware detected - version: 0.36 > > > [ 114.028703] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor > > Request 0x06 failed for offset 0x0404 with error -71 > > > > > > The last error there does not seem to affect the operation of the device. > > > > > > Logs of not working with kernel 5.3.1, 5.2.7 has similar output. > > > sep 26 17:06:12 kernel: ieee80211 phy0: rt2x00_set_rt: Info - RT chipset > > 3070, rev 0201 detected > > > sep 26 17:06:12 kernel: ieee80211 phy0: rt2x00_set_rf: Info - RF chipset > > 0005 detected > > > sep 26 17:06:12 kernel: ieee80211 phy0: Selected rate control algorithm > > 'minstrel_ht' > > > sep 26 17:06:12 kernel: usbcore: registered new interface driver > > rt2800usb > > > sep 26 17:06:12 systemd[1]: Found device RT2870/RT3070 Wireless Adapter. > > > sep 26 17:06:21 ieee80211 phy0: rt2x00lib_request_firmware: Info - > > Loading firmware file 'rt2870.bin' > > > sep 26 17:06:21 ieee80211 phy0: rt2x00lib_request_firmware: Info - > > Firmware detected - version: 0.36 > > > sep 26 17:06:21 ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor > > Request 0x06 failed for offset 0x0404 with> > > > sep 26 17:06:22 ieee80211 phy0: rt2800_wait_csr_ready: Error - Unstable > > hardware > > > sep 26 17:06:22 ieee80211 phy0: rt2800usb_set_device_state: Error - > > Device failed to enter state 4 (-5) > > > > > > Unable to bring up the network interface here. > > > > This most likely is the problem introduced by commit: > > > > commit e383c70474db32b9d4a3de6dfbd08784d19e6751 > > Author: Stanislaw Gruszka <sgruszka@redhat.com> > > Date: Tue Mar 12 10:51:42 2019 +0100 > > > > rt2x00: check number of EPROTO errors > > > > Plase check below patch that increase number of EPROTO checks > > before marking device removed. If it does not help, plese > > check if reverting above commits helps. > > > > diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c > > b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c > > index bc2dfef0de22..215c3f092306 100644 > > --- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c > > +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c > > @@ -30,7 +30,7 @@ static bool rt2x00usb_check_usb_error(struct rt2x00_dev > > *rt2x00dev, int status) > > else > > rt2x00dev->num_proto_errs = 0; > > > > - if (rt2x00dev->num_proto_errs > 3) > > + if (rt2x00dev->num_proto_errs > 8) > > return true; > > > > return false; > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: rt2x00 regression 2019-12-03 7:57 ` Stanislaw Gruszka @ 2019-12-03 18:50 ` Anton Olsson 2020-04-05 4:58 ` Anton Olsson 0 siblings, 1 reply; 20+ messages in thread From: Anton Olsson @ 2019-12-03 18:50 UTC (permalink / raw) To: Stanislaw Gruszka; +Cc: linux-wireless, Helmut Schaa | So, revert of that commit makes the problem gone ? No I have not yet tested that. Have had too much stuff going on and this is kinda low priority for me right now as it currently works on the old kernel. On 2019-12-03 08:57, Stanislaw Gruszka wrote: > On Mon, Dec 02, 2019 at 05:40:20PM +0100, Exuvo wrote: >> Sorry for the late reply >> >> The patch for increasing the amount did not work, i'll get around to >> testing with the commit reverted. > So, revert of that commit makes the problem gone ? > >> As an aside what function can i call at that point in the code to print the >> value in num_proto_errs? I assume some kernel special printf? > It's printk. You can add line like this to print values: > > printk("status %d num_proto_errs %u\n", status, rt2x00dev->num_proto_errs); > > Stanislaw > > >> On Fri, 27 Sep 2019, 10:03 Stanislaw Gruszka, <sgruszka@redhat.com> wrote: >> >>> On Thu, Sep 26, 2019 at 06:32:23PM +0200, Anton Olsson wrote: >>>> Hello I have a USB based ID 148f:3070 Ralink Technology, Corp. >>> RT2870/RT3070 Wireless Adapter, that stops working with recent kernels. It >>> works on kernel 5.1.15 and does not work with 5.2.7 or 5.3.1 (I have not >>> tested other versions). I use it in AP mode. >>>> I found this similar bug report >>> https://marc.info/?l=linux-wireless&m=156630037103575&w=2 but that did >>> not have related error messages so I assume this is different? >>>> Logs of working kernel 5.1.15-arch1-1-ARCH. >>>> [ 78.680555] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 3070, >>> rev 0201 detected >>>> [ 78.690992] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0005 >>> detected >>>> [ 78.799625] ieee80211 phy0: Selected rate control algorithm >>> 'minstrel_ht' >>>> sep 26 17:13:03 kernel: usbcore: registered new interface driver >>> rt2800usb >>>> sep 26 17:13:03 systemd[1]: Found device RT2870/RT3070 Wireless Adapter. >>>> [ 113.812454] ieee80211 phy0: rt2x00lib_request_firmware: Info - >>> Loading firmware file 'rt2870.bin' >>>> [ 113.905279] ieee80211 phy0: rt2x00lib_request_firmware: Info - >>> Firmware detected - version: 0.36 >>>> [ 114.028703] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor >>> Request 0x06 failed for offset 0x0404 with error -71 >>>> The last error there does not seem to affect the operation of the device. >>>> >>>> Logs of not working with kernel 5.3.1, 5.2.7 has similar output. >>>> sep 26 17:06:12 kernel: ieee80211 phy0: rt2x00_set_rt: Info - RT chipset >>> 3070, rev 0201 detected >>>> sep 26 17:06:12 kernel: ieee80211 phy0: rt2x00_set_rf: Info - RF chipset >>> 0005 detected >>>> sep 26 17:06:12 kernel: ieee80211 phy0: Selected rate control algorithm >>> 'minstrel_ht' >>>> sep 26 17:06:12 kernel: usbcore: registered new interface driver >>> rt2800usb >>>> sep 26 17:06:12 systemd[1]: Found device RT2870/RT3070 Wireless Adapter. >>>> sep 26 17:06:21 ieee80211 phy0: rt2x00lib_request_firmware: Info - >>> Loading firmware file 'rt2870.bin' >>>> sep 26 17:06:21 ieee80211 phy0: rt2x00lib_request_firmware: Info - >>> Firmware detected - version: 0.36 >>>> sep 26 17:06:21 ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor >>> Request 0x06 failed for offset 0x0404 with> >>>> sep 26 17:06:22 ieee80211 phy0: rt2800_wait_csr_ready: Error - Unstable >>> hardware >>>> sep 26 17:06:22 ieee80211 phy0: rt2800usb_set_device_state: Error - >>> Device failed to enter state 4 (-5) >>>> Unable to bring up the network interface here. >>> This most likely is the problem introduced by commit: >>> >>> commit e383c70474db32b9d4a3de6dfbd08784d19e6751 >>> Author: Stanislaw Gruszka <sgruszka@redhat.com> >>> Date: Tue Mar 12 10:51:42 2019 +0100 >>> >>> rt2x00: check number of EPROTO errors >>> >>> Plase check below patch that increase number of EPROTO checks >>> before marking device removed. If it does not help, plese >>> check if reverting above commits helps. >>> >>> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c >>> b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c >>> index bc2dfef0de22..215c3f092306 100644 >>> --- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c >>> +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c >>> @@ -30,7 +30,7 @@ static bool rt2x00usb_check_usb_error(struct rt2x00_dev >>> *rt2x00dev, int status) >>> else >>> rt2x00dev->num_proto_errs = 0; >>> >>> - if (rt2x00dev->num_proto_errs > 3) >>> + if (rt2x00dev->num_proto_errs > 8) >>> return true; >>> >>> return false; >>> ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: rt2x00 regression 2019-12-03 18:50 ` Anton Olsson @ 2020-04-05 4:58 ` Anton Olsson 2020-07-15 19:47 ` Anton Olsson 0 siblings, 1 reply; 20+ messages in thread From: Anton Olsson @ 2020-04-05 4:58 UTC (permalink / raw) To: Stanislaw Gruszka; +Cc: linux-wireless, Helmut Schaa So i got around to this again: Changes to linux-5.6.0 drivers/net/wireless/ralink/rt2x00/rt2x00usb.c were: static bool rt2x00usb_check_usb_error(struct rt2x00_dev *rt2x00dev, int status) { if (status == -ENODEV || status == -ENOENT) return true; if (status == -EPROTO || status == -ETIMEDOUT) { rt2x00dev->num_proto_errs++; + printk("status %d num_proto_errs %u\n", status, rt2x00dev->num_proto_errs); } else rt2x00dev->num_proto_errs = 0; - if (rt2x00dev->num_proto_errs > 8) - return true; return false; } Relevant dmesg of boot: [ 37.342405] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 3070, rev 0201 detected [ 37.353368] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0005 detected [ 37.353679] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' [ 37.355695] usbcore: registered new interface driver rt2800usb [ 37.357728] rt2800usb 1-3:1.0 wifi: renamed from wlan0 [ 72.631902] ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin' [ 72.702655] ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.36 [ 72.728619] status -71 num_proto_errs 1 [ 72.728733] status -71 num_proto_errs 2 [ 72.728847] status -71 num_proto_errs 3 --same error with nothing else between-- [ 72.827518] status -71 num_proto_errs 883 [ 72.827520] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x0404 with error -71 [ 72.908595] status -71 num_proto_errs 884 --same error with nothing else between except ip-table firewall drops-- [ 74.651391] status -71 num_proto_errs 935 [ 80.098903] IPv6: ADDRCONF(NETDEV_CHANGE): wifi: link becomes ready -- No more errors after this even when using device in AP mode-- As the error count is very high at the start but no more errors after that i assume some part of the initialization is not supported by my device, any suggestions how to figure out what exactly? Device works fine afterwards, but i have not done any serious connection testing beyond simple transfer test, getting 3MB/s sustained transfer rate both ways which is enough for me. Anton 'exuvo' Olsson +46732193727 http://exuvo.se On 2019-12-03 19:50, Anton Olsson wrote: > | So, revert of that commit makes the problem gone ? > > No I have not yet tested that. Have had too much stuff going on and this is kinda low priority for me right now as it currently works on the old kernel. > > On 2019-12-03 08:57, Stanislaw Gruszka wrote: >> On Mon, Dec 02, 2019 at 05:40:20PM +0100, Exuvo wrote: >>> Sorry for the late reply >>> >>> The patch for increasing the amount did not work, i'll get around to >>> testing with the commit reverted. >> So, revert of that commit makes the problem gone ? >> >>> As an aside what function can i call at that point in the code to print the >>> value in num_proto_errs? I assume some kernel special printf? >> It's printk. You can add line like this to print values: >> >> printk("status %d num_proto_errs %u\n", status, rt2x00dev->num_proto_errs); >> >> Stanislaw >> >> >>> On Fri, 27 Sep 2019, 10:03 Stanislaw Gruszka, <sgruszka@redhat.com> wrote: >>> >>>> On Thu, Sep 26, 2019 at 06:32:23PM +0200, Anton Olsson wrote: >>>>> Hello I have a USB based ID 148f:3070 Ralink Technology, Corp. >>>> RT2870/RT3070 Wireless Adapter, that stops working with recent kernels. It >>>> works on kernel 5.1.15 and does not work with 5.2.7 or 5.3.1 (I have not >>>> tested other versions). I use it in AP mode. >>>>> I found this similar bug report >>>> https://marc.info/?l=linux-wireless&m=156630037103575&w=2 but that did >>>> not have related error messages so I assume this is different? >>>>> Logs of working kernel 5.1.15-arch1-1-ARCH. >>>>> [ 78.680555] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 3070, >>>> rev 0201 detected >>>>> [ 78.690992] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0005 >>>> detected >>>>> [ 78.799625] ieee80211 phy0: Selected rate control algorithm >>>> 'minstrel_ht' >>>>> sep 26 17:13:03 kernel: usbcore: registered new interface driver >>>> rt2800usb >>>>> sep 26 17:13:03 systemd[1]: Found device RT2870/RT3070 Wireless Adapter. >>>>> [ 113.812454] ieee80211 phy0: rt2x00lib_request_firmware: Info - >>>> Loading firmware file 'rt2870.bin' >>>>> [ 113.905279] ieee80211 phy0: rt2x00lib_request_firmware: Info - >>>> Firmware detected - version: 0.36 >>>>> [ 114.028703] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor >>>> Request 0x06 failed for offset 0x0404 with error -71 >>>>> The last error there does not seem to affect the operation of the device. >>>>> >>>>> Logs of not working with kernel 5.3.1, 5.2.7 has similar output. >>>>> sep 26 17:06:12 kernel: ieee80211 phy0: rt2x00_set_rt: Info - RT chipset >>>> 3070, rev 0201 detected >>>>> sep 26 17:06:12 kernel: ieee80211 phy0: rt2x00_set_rf: Info - RF chipset >>>> 0005 detected >>>>> sep 26 17:06:12 kernel: ieee80211 phy0: Selected rate control algorithm >>>> 'minstrel_ht' >>>>> sep 26 17:06:12 kernel: usbcore: registered new interface driver >>>> rt2800usb >>>>> sep 26 17:06:12 systemd[1]: Found device RT2870/RT3070 Wireless Adapter. >>>>> sep 26 17:06:21 ieee80211 phy0: rt2x00lib_request_firmware: Info - >>>> Loading firmware file 'rt2870.bin' >>>>> sep 26 17:06:21 ieee80211 phy0: rt2x00lib_request_firmware: Info - >>>> Firmware detected - version: 0.36 >>>>> sep 26 17:06:21 ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor >>>> Request 0x06 failed for offset 0x0404 with> >>>>> sep 26 17:06:22 ieee80211 phy0: rt2800_wait_csr_ready: Error - Unstable >>>> hardware >>>>> sep 26 17:06:22 ieee80211 phy0: rt2800usb_set_device_state: Error - >>>> Device failed to enter state 4 (-5) >>>>> Unable to bring up the network interface here. >>>> This most likely is the problem introduced by commit: >>>> >>>> commit e383c70474db32b9d4a3de6dfbd08784d19e6751 >>>> Author: Stanislaw Gruszka <sgruszka@redhat.com> >>>> Date: Tue Mar 12 10:51:42 2019 +0100 >>>> >>>> rt2x00: check number of EPROTO errors >>>> >>>> Plase check below patch that increase number of EPROTO checks >>>> before marking device removed. If it does not help, plese >>>> check if reverting above commits helps. >>>> >>>> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c >>>> b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c >>>> index bc2dfef0de22..215c3f092306 100644 >>>> --- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c >>>> +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c >>>> @@ -30,7 +30,7 @@ static bool rt2x00usb_check_usb_error(struct rt2x00_dev >>>> *rt2x00dev, int status) >>>> else >>>> rt2x00dev->num_proto_errs = 0; >>>> >>>> - if (rt2x00dev->num_proto_errs > 3) >>>> + if (rt2x00dev->num_proto_errs > 8) >>>> return true; >>>> >>>> return false; >>>> ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: rt2x00 regression 2020-04-05 4:58 ` Anton Olsson @ 2020-07-15 19:47 ` Anton Olsson 2021-09-29 8:22 ` Exuvo 0 siblings, 1 reply; 20+ messages in thread From: Anton Olsson @ 2020-07-15 19:47 UTC (permalink / raw) To: Stanislaw Gruszka; +Cc: linux-wireless, Helmut Schaa I added a dump_stack() call below the printk to help to narrow it down more. Whole dump_stack part from boot http://exuvo.se/f/kernel-5.7.8-wifi-dumpstack Excerps: 2020-07-15T19:16:02.121091+0000 kernel: status -71 num_proto_errs 1 2020-07-15T19:16:02.121214+0000 kernel: CPU: 3 PID: 700 Comm: ip Tainted: G I 5.7.8-arch1-1-custom #1 2020-07-15T19:16:02.121276+0000 kernel: Hardware name: MSI MS-7994/H110M ECO (MS-7994), BIOS 2.00 11/26/2015 2020-07-15T19:16:02.121385+0000 kernel: Call Trace: 2020-07-15T19:16:02.121461+0000 kernel: dump_stack+0x64/0x88 2020-07-15T19:16:02.121548+0000 kernel: rt2x00usb_vendor_request.cold+0x2b/0x69 [rt2x00usb] 2020-07-15T19:16:02.121633+0000 kernel: rt2x00usb_vendor_req_buff_lock+0xa6/0x230 [rt2x00usb] 2020-07-15T19:16:02.121685+0000 kernel: rt2x00usb_register_write_lock+0x37/0x60 [rt2800usb] 2020-07-15T19:16:02.121767+0000 kernel: rt2800_mcu_request+0x100/0x110 [rt2800lib] 2020-07-15T19:16:02.121823+0000 kernel: rt2800_load_firmware+0x1a9/0x390 [rt2800lib] 2020-07-15T19:16:02.121873+0000 kernel: rt2x00lib_load_firmware+0x52/0xd0 [rt2x00lib] 2020-07-15T19:16:02.121984+0000 kernel: rt2x00lib_start+0x12/0xc0 [rt2x00lib] 2020-07-15T19:16:02.122084+0000 kernel: drv_start+0x3e/0x130 [mac80211] load_firmware continues until errr 509 2020-07-15T19:16:10.954842+0000 kernel: status -71 num_proto_errs 508 2020-07-15T19:16:10.954861+0000 kernel: CPU: 2 PID: 723 Comm: hostapd Tainted: G I 5.7.8-arch1-1-custom #1 2020-07-15T19:16:10.954880+0000 kernel: Hardware name: MSI MS-7994/H110M ECO (MS-7994), BIOS 2.00 11/26/2015 2020-07-15T19:16:10.954894+0000 kernel: Call Trace: 2020-07-15T19:16:10.954908+0000 kernel: dump_stack+0x64/0x88 2020-07-15T19:16:10.954926+0000 kernel: rt2x00usb_vendor_request.cold+0x2b/0x69 [rt2x00usb] 2020-07-15T19:16:10.954947+0000 kernel: rt2x00usb_vendor_req_buff_lock+0xa6/0x230 [rt2x00usb] 2020-07-15T19:16:10.954966+0000 kernel: rt2x00usb_register_write_lock+0x37/0x60 [rt2800usb] 2020-07-15T19:16:10.954980+0000 kernel: rt2800_mcu_request+0x100/0x110 [rt2800lib] 2020-07-15T19:16:10.954998+0000 kernel: rt2800_load_firmware+0x1a9/0x390 [rt2800lib] 2020-07-15T19:16:10.955013+0000 kernel: rt2x00lib_load_firmware+0x52/0xd0 [rt2x00lib] 2020-07-15T19:16:10.955026+0000 kernel: rt2x00lib_start+0x12/0xc0 [rt2x00lib] 2020-07-15T19:16:10.955040+0000 kernel: drv_start+0x3e/0x130 [mac80211] 2020-07-15T19:16:10.955378+0000 kernel: status -71 num_proto_errs 509 2020-07-15T19:16:10.955404+0000 kernel: CPU: 1 PID: 723 Comm: hostapd Tainted: G I 5.7.8-arch1-1-custom #1 2020-07-15T19:16:10.956581+0000 kernel: Hardware name: MSI MS-7994/H110M ECO (MS-7994), BIOS 2.00 11/26/2015 2020-07-15T19:16:10.956602+0000 kernel: Call Trace: 2020-07-15T19:16:10.956620+0000 kernel: dump_stack+0x64/0x88 2020-07-15T19:16:10.956635+0000 kernel: rt2x00usb_vendor_request.cold+0x2b/0x69 [rt2x00usb] 2020-07-15T19:16:10.956649+0000 kernel: rt2x00usb_vendor_req_buff_lock+0xa6/0x230 [rt2x00usb] 2020-07-15T19:16:10.956663+0000 kernel: rt2x00usb_register_write_lock+0x37/0x60 [rt2800usb] 2020-07-15T19:16:10.956677+0000 kernel: rt2800_mcu_request+0x100/0x110 [rt2800lib] 2020-07-15T19:16:10.956696+0000 kernel: rt2800_enable_radio+0xb6/0x2d36 [rt2800lib] 2020-07-15T19:16:10.956712+0000 kernel: rt2800usb_set_device_state+0xbd/0x18b [rt2800usb] 2020-07-15T19:16:10.956735+0000 kernel: rt2x00lib_enable_radio+0x3e/0xa0 [rt2x00lib] 2020-07-15T19:16:10.956754+0000 kernel: rt2x00lib_start+0x7c/0xc0 [rt2x00lib] 2020-07-15T19:16:10.956778+0000 kernel: drv_start+0x3e/0x130 [mac80211] and 509 is the last error, so it seems like it is the load_firmware process that is giving all the errors. As clarification device works after this with no further errors when using. Anton 'exuvo' Olsson +46732193727 http://exuvo.se On 2020-04-05 06:58, Anton Olsson wrote: > So i got around to this again: > > Changes to linux-5.6.0 drivers/net/wireless/ralink/rt2x00/rt2x00usb.c were: > > static bool rt2x00usb_check_usb_error(struct rt2x00_dev *rt2x00dev, int status) > { > if (status == -ENODEV || status == -ENOENT) > return true; > > if (status == -EPROTO || status == -ETIMEDOUT) { > rt2x00dev->num_proto_errs++; > + printk("status %d num_proto_errs %u\n", status, rt2x00dev->num_proto_errs); > } else > rt2x00dev->num_proto_errs = 0; > > - if (rt2x00dev->num_proto_errs > 8) > - return true; > > return false; > } > > Relevant dmesg of boot: > [ 37.342405] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 3070, rev 0201 detected > [ 37.353368] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0005 detected > [ 37.353679] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' > [ 37.355695] usbcore: registered new interface driver rt2800usb > [ 37.357728] rt2800usb 1-3:1.0 wifi: renamed from wlan0 > [ 72.631902] ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin' > [ 72.702655] ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.36 > [ 72.728619] status -71 num_proto_errs 1 > [ 72.728733] status -71 num_proto_errs 2 > [ 72.728847] status -71 num_proto_errs 3 > --same error with nothing else between-- > [ 72.827518] status -71 num_proto_errs 883 > [ 72.827520] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x0404 with error -71 > [ 72.908595] status -71 num_proto_errs 884 > --same error with nothing else between except ip-table firewall drops-- > [ 74.651391] status -71 num_proto_errs 935 > [ 80.098903] IPv6: ADDRCONF(NETDEV_CHANGE): wifi: link becomes ready > -- No more errors after this even when using device in AP mode-- > > As the error count is very high at the start but no more errors after that i assume some part of the initialization is not supported by my device, any suggestions how to figure out what exactly? Device works fine afterwards, but i have not done any serious connection testing beyond simple transfer test, getting 3MB/s sustained transfer rate both ways which is enough for me. > > Anton 'exuvo' Olsson > +46732193727 > http://exuvo.se > > On 2019-12-03 19:50, Anton Olsson wrote: >> | So, revert of that commit makes the problem gone ? >> >> No I have not yet tested that. Have had too much stuff going on and this is kinda low priority for me right now as it currently works on the old kernel. >> >> On 2019-12-03 08:57, Stanislaw Gruszka wrote: >>> On Mon, Dec 02, 2019 at 05:40:20PM +0100, Exuvo wrote: >>>> Sorry for the late reply >>>> >>>> The patch for increasing the amount did not work, i'll get around to >>>> testing with the commit reverted. >>> So, revert of that commit makes the problem gone ? >>> >>>> As an aside what function can i call at that point in the code to print the >>>> value in num_proto_errs? I assume some kernel special printf? >>> It's printk. You can add line like this to print values: >>> >>> printk("status %d num_proto_errs %u\n", status, rt2x00dev->num_proto_errs); >>> >>> Stanislaw >>> >>> >>>> On Fri, 27 Sep 2019, 10:03 Stanislaw Gruszka, <sgruszka@redhat.com> wrote: >>>> >>>>> On Thu, Sep 26, 2019 at 06:32:23PM +0200, Anton Olsson wrote: >>>>>> Hello I have a USB based ID 148f:3070 Ralink Technology, Corp. >>>>> RT2870/RT3070 Wireless Adapter, that stops working with recent kernels. It >>>>> works on kernel 5.1.15 and does not work with 5.2.7 or 5.3.1 (I have not >>>>> tested other versions). I use it in AP mode. >>>>>> I found this similar bug report >>>>> https://marc.info/?l=linux-wireless&m=156630037103575&w=2 but that did >>>>> not have related error messages so I assume this is different? >>>>>> Logs of working kernel 5.1.15-arch1-1-ARCH. >>>>>> [ 78.680555] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 3070, >>>>> rev 0201 detected >>>>>> [ 78.690992] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0005 >>>>> detected >>>>>> [ 78.799625] ieee80211 phy0: Selected rate control algorithm >>>>> 'minstrel_ht' >>>>>> sep 26 17:13:03 kernel: usbcore: registered new interface driver >>>>> rt2800usb >>>>>> sep 26 17:13:03 systemd[1]: Found device RT2870/RT3070 Wireless Adapter. >>>>>> [ 113.812454] ieee80211 phy0: rt2x00lib_request_firmware: Info - >>>>> Loading firmware file 'rt2870.bin' >>>>>> [ 113.905279] ieee80211 phy0: rt2x00lib_request_firmware: Info - >>>>> Firmware detected - version: 0.36 >>>>>> [ 114.028703] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor >>>>> Request 0x06 failed for offset 0x0404 with error -71 >>>>>> The last error there does not seem to affect the operation of the device. >>>>>> >>>>>> Logs of not working with kernel 5.3.1, 5.2.7 has similar output. >>>>>> sep 26 17:06:12 kernel: ieee80211 phy0: rt2x00_set_rt: Info - RT chipset >>>>> 3070, rev 0201 detected >>>>>> sep 26 17:06:12 kernel: ieee80211 phy0: rt2x00_set_rf: Info - RF chipset >>>>> 0005 detected >>>>>> sep 26 17:06:12 kernel: ieee80211 phy0: Selected rate control algorithm >>>>> 'minstrel_ht' >>>>>> sep 26 17:06:12 kernel: usbcore: registered new interface driver >>>>> rt2800usb >>>>>> sep 26 17:06:12 systemd[1]: Found device RT2870/RT3070 Wireless Adapter. >>>>>> sep 26 17:06:21 ieee80211 phy0: rt2x00lib_request_firmware: Info - >>>>> Loading firmware file 'rt2870.bin' >>>>>> sep 26 17:06:21 ieee80211 phy0: rt2x00lib_request_firmware: Info - >>>>> Firmware detected - version: 0.36 >>>>>> sep 26 17:06:21 ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor >>>>> Request 0x06 failed for offset 0x0404 with> >>>>>> sep 26 17:06:22 ieee80211 phy0: rt2800_wait_csr_ready: Error - Unstable >>>>> hardware >>>>>> sep 26 17:06:22 ieee80211 phy0: rt2800usb_set_device_state: Error - >>>>> Device failed to enter state 4 (-5) >>>>>> Unable to bring up the network interface here. >>>>> This most likely is the problem introduced by commit: >>>>> >>>>> commit e383c70474db32b9d4a3de6dfbd08784d19e6751 >>>>> Author: Stanislaw Gruszka <sgruszka@redhat.com> >>>>> Date: Tue Mar 12 10:51:42 2019 +0100 >>>>> >>>>> rt2x00: check number of EPROTO errors >>>>> >>>>> Plase check below patch that increase number of EPROTO checks >>>>> before marking device removed. If it does not help, plese >>>>> check if reverting above commits helps. >>>>> >>>>> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c >>>>> b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c >>>>> index bc2dfef0de22..215c3f092306 100644 >>>>> --- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c >>>>> +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c >>>>> @@ -30,7 +30,7 @@ static bool rt2x00usb_check_usb_error(struct rt2x00_dev >>>>> *rt2x00dev, int status) >>>>> else >>>>> rt2x00dev->num_proto_errs = 0; >>>>> >>>>> - if (rt2x00dev->num_proto_errs > 3) >>>>> + if (rt2x00dev->num_proto_errs > 8) >>>>> return true; >>>>> >>>>> return false; >>>>> ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: rt2x00 regression 2020-07-15 19:47 ` Anton Olsson @ 2021-09-29 8:22 ` Exuvo 2021-10-01 6:56 ` Kalle Valo 0 siblings, 1 reply; 20+ messages in thread From: Exuvo @ 2021-09-29 8:22 UTC (permalink / raw) To: Stanislaw Gruszka; +Cc: linux-wireless, Helmut Schaa I would like to get this resolved, is there any more information you need from me? I have been manually patching this all year with: drivers/net/wireless/ralink/rt2x00/rt2x00usb.c - if (rt2x00dev->num_proto_errs > 8) - return true; It seems to just be some part of rt2800_load_firmware that is not supported on my device and generating errors but it has been running without problems in AP mode with daily usage. lsusb -v (with unpatched linux-lts, i don't normally use lts kernel): Bus 001 Device 002: ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070 Wireless Adapter Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x148f Ralink Technology, Corp. idProduct 0x3070 RT2870/RT3070 Wireless Adapter bcdDevice 1.01 iManufacturer 1 Ralink iProduct 2 802.11 n WLAN iSerial 3 1.0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0043 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 450mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 7 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 5 1.0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x06 EP 6 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0000 (Bus Powered) Anton "exuvo" Olsson exuvo@exuvo.se On 2020-07-15 21:47, Anton Olsson wrote: > I added a dump_stack() call below the printk to help to narrow it down more. > Whole dump_stack part from boot http://exuvo.se/f/kernel-5.7.8-wifi-dumpstack > > Excerps: > 2020-07-15T19:16:02.121091+0000 kernel: status -71 num_proto_errs 1 > 2020-07-15T19:16:02.121214+0000 kernel: CPU: 3 PID: 700 Comm: ip Tainted: G I 5.7.8-arch1-1-custom #1 > 2020-07-15T19:16:02.121276+0000 kernel: Hardware name: MSI MS-7994/H110M ECO (MS-7994), BIOS 2.00 11/26/2015 > 2020-07-15T19:16:02.121385+0000 kernel: Call Trace: > 2020-07-15T19:16:02.121461+0000 kernel: dump_stack+0x64/0x88 > 2020-07-15T19:16:02.121548+0000 kernel: rt2x00usb_vendor_request.cold+0x2b/0x69 [rt2x00usb] > 2020-07-15T19:16:02.121633+0000 kernel: rt2x00usb_vendor_req_buff_lock+0xa6/0x230 [rt2x00usb] > 2020-07-15T19:16:02.121685+0000 kernel: rt2x00usb_register_write_lock+0x37/0x60 [rt2800usb] > 2020-07-15T19:16:02.121767+0000 kernel: rt2800_mcu_request+0x100/0x110 [rt2800lib] > 2020-07-15T19:16:02.121823+0000 kernel: rt2800_load_firmware+0x1a9/0x390 [rt2800lib] > 2020-07-15T19:16:02.121873+0000 kernel: rt2x00lib_load_firmware+0x52/0xd0 [rt2x00lib] > 2020-07-15T19:16:02.121984+0000 kernel: rt2x00lib_start+0x12/0xc0 [rt2x00lib] > 2020-07-15T19:16:02.122084+0000 kernel: drv_start+0x3e/0x130 [mac80211] > > load_firmware continues until errr 509 > > 2020-07-15T19:16:10.954842+0000 kernel: status -71 num_proto_errs 508 > 2020-07-15T19:16:10.954861+0000 kernel: CPU: 2 PID: 723 Comm: hostapd Tainted: G I 5.7.8-arch1-1-custom #1 > 2020-07-15T19:16:10.954880+0000 kernel: Hardware name: MSI MS-7994/H110M ECO (MS-7994), BIOS 2.00 11/26/2015 > 2020-07-15T19:16:10.954894+0000 kernel: Call Trace: > 2020-07-15T19:16:10.954908+0000 kernel: dump_stack+0x64/0x88 > 2020-07-15T19:16:10.954926+0000 kernel: rt2x00usb_vendor_request.cold+0x2b/0x69 [rt2x00usb] > 2020-07-15T19:16:10.954947+0000 kernel: rt2x00usb_vendor_req_buff_lock+0xa6/0x230 [rt2x00usb] > 2020-07-15T19:16:10.954966+0000 kernel: rt2x00usb_register_write_lock+0x37/0x60 [rt2800usb] > 2020-07-15T19:16:10.954980+0000 kernel: rt2800_mcu_request+0x100/0x110 [rt2800lib] > 2020-07-15T19:16:10.954998+0000 kernel: rt2800_load_firmware+0x1a9/0x390 [rt2800lib] > 2020-07-15T19:16:10.955013+0000 kernel: rt2x00lib_load_firmware+0x52/0xd0 [rt2x00lib] > 2020-07-15T19:16:10.955026+0000 kernel: rt2x00lib_start+0x12/0xc0 [rt2x00lib] > 2020-07-15T19:16:10.955040+0000 kernel: drv_start+0x3e/0x130 [mac80211] > > 2020-07-15T19:16:10.955378+0000 kernel: status -71 num_proto_errs 509 > 2020-07-15T19:16:10.955404+0000 kernel: CPU: 1 PID: 723 Comm: hostapd Tainted: G I 5.7.8-arch1-1-custom #1 > 2020-07-15T19:16:10.956581+0000 kernel: Hardware name: MSI MS-7994/H110M ECO (MS-7994), BIOS 2.00 11/26/2015 > 2020-07-15T19:16:10.956602+0000 kernel: Call Trace: > 2020-07-15T19:16:10.956620+0000 kernel: dump_stack+0x64/0x88 > 2020-07-15T19:16:10.956635+0000 kernel: rt2x00usb_vendor_request.cold+0x2b/0x69 [rt2x00usb] > 2020-07-15T19:16:10.956649+0000 kernel: rt2x00usb_vendor_req_buff_lock+0xa6/0x230 [rt2x00usb] > 2020-07-15T19:16:10.956663+0000 kernel: rt2x00usb_register_write_lock+0x37/0x60 [rt2800usb] > 2020-07-15T19:16:10.956677+0000 kernel: rt2800_mcu_request+0x100/0x110 [rt2800lib] > 2020-07-15T19:16:10.956696+0000 kernel: rt2800_enable_radio+0xb6/0x2d36 [rt2800lib] > 2020-07-15T19:16:10.956712+0000 kernel: rt2800usb_set_device_state+0xbd/0x18b [rt2800usb] > 2020-07-15T19:16:10.956735+0000 kernel: rt2x00lib_enable_radio+0x3e/0xa0 [rt2x00lib] > 2020-07-15T19:16:10.956754+0000 kernel: rt2x00lib_start+0x7c/0xc0 [rt2x00lib] > 2020-07-15T19:16:10.956778+0000 kernel: drv_start+0x3e/0x130 [mac80211] > > and 509 is the last error, so it seems like it is the load_firmware process that is giving all the errors. > > As clarification device works after this with no further errors when using. > > Anton 'exuvo' Olsson > +46732193727 > http://exuvo.se > > On 2020-04-05 06:58, Anton Olsson wrote: >> So i got around to this again: >> >> Changes to linux-5.6.0 drivers/net/wireless/ralink/rt2x00/rt2x00usb.c were: >> >> static bool rt2x00usb_check_usb_error(struct rt2x00_dev *rt2x00dev, int status) >> { >> if (status == -ENODEV || status == -ENOENT) >> return true; >> >> if (status == -EPROTO || status == -ETIMEDOUT) { >> rt2x00dev->num_proto_errs++; >> + printk("status %d num_proto_errs %u\n", status, rt2x00dev->num_proto_errs); >> } else >> rt2x00dev->num_proto_errs = 0; >> >> - if (rt2x00dev->num_proto_errs > 8) >> - return true; >> >> return false; >> } >> >> Relevant dmesg of boot: >> [ 37.342405] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 3070, rev 0201 detected >> [ 37.353368] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0005 detected >> [ 37.353679] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' >> [ 37.355695] usbcore: registered new interface driver rt2800usb >> [ 37.357728] rt2800usb 1-3:1.0 wifi: renamed from wlan0 >> [ 72.631902] ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin' >> [ 72.702655] ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.36 >> [ 72.728619] status -71 num_proto_errs 1 >> [ 72.728733] status -71 num_proto_errs 2 >> [ 72.728847] status -71 num_proto_errs 3 >> --same error with nothing else between-- >> [ 72.827518] status -71 num_proto_errs 883 >> [ 72.827520] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x0404 with error -71 >> [ 72.908595] status -71 num_proto_errs 884 >> --same error with nothing else between except ip-table firewall drops-- >> [ 74.651391] status -71 num_proto_errs 935 >> [ 80.098903] IPv6: ADDRCONF(NETDEV_CHANGE): wifi: link becomes ready >> -- No more errors after this even when using device in AP mode-- >> >> As the error count is very high at the start but no more errors after that i assume some part of the initialization is not supported by my device, any suggestions how to figure out what exactly? Device works fine afterwards, but i have not done any serious connection testing beyond simple transfer test, getting 3MB/s sustained transfer rate both ways which is enough for me. >> >> Anton 'exuvo' Olsson >> +46732193727 >> http://exuvo.se >> >> On 2019-12-03 19:50, Anton Olsson wrote: >>> | So, revert of that commit makes the problem gone ? >>> >>> No I have not yet tested that. Have had too much stuff going on and this is kinda low priority for me right now as it currently works on the old kernel. >>> >>> On 2019-12-03 08:57, Stanislaw Gruszka wrote: >>>> On Mon, Dec 02, 2019 at 05:40:20PM +0100, Exuvo wrote: >>>>> Sorry for the late reply >>>>> >>>>> The patch for increasing the amount did not work, i'll get around to >>>>> testing with the commit reverted. >>>> So, revert of that commit makes the problem gone ? >>>> >>>>> As an aside what function can i call at that point in the code to print the >>>>> value in num_proto_errs? I assume some kernel special printf? >>>> It's printk. You can add line like this to print values: >>>> >>>> printk("status %d num_proto_errs %u\n", status, rt2x00dev->num_proto_errs); >>>> >>>> Stanislaw >>>> >>>> >>>>> On Fri, 27 Sep 2019, 10:03 Stanislaw Gruszka, <sgruszka@redhat.com> wrote: >>>>> >>>>>> On Thu, Sep 26, 2019 at 06:32:23PM +0200, Anton Olsson wrote: >>>>>>> Hello I have a USB based ID 148f:3070 Ralink Technology, Corp. >>>>>> RT2870/RT3070 Wireless Adapter, that stops working with recent kernels. It >>>>>> works on kernel 5.1.15 and does not work with 5.2.7 or 5.3.1 (I have not >>>>>> tested other versions). I use it in AP mode. >>>>>>> I found this similar bug report >>>>>> https://marc.info/?l=linux-wireless&m=156630037103575&w=2 but that did >>>>>> not have related error messages so I assume this is different? >>>>>>> Logs of working kernel 5.1.15-arch1-1-ARCH. >>>>>>> [ 78.680555] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 3070, >>>>>> rev 0201 detected >>>>>>> [ 78.690992] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0005 >>>>>> detected >>>>>>> [ 78.799625] ieee80211 phy0: Selected rate control algorithm >>>>>> 'minstrel_ht' >>>>>>> sep 26 17:13:03 kernel: usbcore: registered new interface driver >>>>>> rt2800usb >>>>>>> sep 26 17:13:03 systemd[1]: Found device RT2870/RT3070 Wireless Adapter. >>>>>>> [ 113.812454] ieee80211 phy0: rt2x00lib_request_firmware: Info - >>>>>> Loading firmware file 'rt2870.bin' >>>>>>> [ 113.905279] ieee80211 phy0: rt2x00lib_request_firmware: Info - >>>>>> Firmware detected - version: 0.36 >>>>>>> [ 114.028703] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor >>>>>> Request 0x06 failed for offset 0x0404 with error -71 >>>>>>> The last error there does not seem to affect the operation of the device. >>>>>>> >>>>>>> Logs of not working with kernel 5.3.1, 5.2.7 has similar output. >>>>>>> sep 26 17:06:12 kernel: ieee80211 phy0: rt2x00_set_rt: Info - RT chipset >>>>>> 3070, rev 0201 detected >>>>>>> sep 26 17:06:12 kernel: ieee80211 phy0: rt2x00_set_rf: Info - RF chipset >>>>>> 0005 detected >>>>>>> sep 26 17:06:12 kernel: ieee80211 phy0: Selected rate control algorithm >>>>>> 'minstrel_ht' >>>>>>> sep 26 17:06:12 kernel: usbcore: registered new interface driver >>>>>> rt2800usb >>>>>>> sep 26 17:06:12 systemd[1]: Found device RT2870/RT3070 Wireless Adapter. >>>>>>> sep 26 17:06:21 ieee80211 phy0: rt2x00lib_request_firmware: Info - >>>>>> Loading firmware file 'rt2870.bin' >>>>>>> sep 26 17:06:21 ieee80211 phy0: rt2x00lib_request_firmware: Info - >>>>>> Firmware detected - version: 0.36 >>>>>>> sep 26 17:06:21 ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor >>>>>> Request 0x06 failed for offset 0x0404 with> >>>>>>> sep 26 17:06:22 ieee80211 phy0: rt2800_wait_csr_ready: Error - Unstable >>>>>> hardware >>>>>>> sep 26 17:06:22 ieee80211 phy0: rt2800usb_set_device_state: Error - >>>>>> Device failed to enter state 4 (-5) >>>>>>> Unable to bring up the network interface here. >>>>>> This most likely is the problem introduced by commit: >>>>>> >>>>>> commit e383c70474db32b9d4a3de6dfbd08784d19e6751 >>>>>> Author: Stanislaw Gruszka <sgruszka@redhat.com> >>>>>> Date: Tue Mar 12 10:51:42 2019 +0100 >>>>>> >>>>>> rt2x00: check number of EPROTO errors >>>>>> >>>>>> Plase check below patch that increase number of EPROTO checks >>>>>> before marking device removed. If it does not help, plese >>>>>> check if reverting above commits helps. >>>>>> >>>>>> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c >>>>>> b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c >>>>>> index bc2dfef0de22..215c3f092306 100644 >>>>>> --- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c >>>>>> +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c >>>>>> @@ -30,7 +30,7 @@ static bool rt2x00usb_check_usb_error(struct rt2x00_dev >>>>>> *rt2x00dev, int status) >>>>>> else >>>>>> rt2x00dev->num_proto_errs = 0; >>>>>> >>>>>> - if (rt2x00dev->num_proto_errs > 3) >>>>>> + if (rt2x00dev->num_proto_errs > 8) >>>>>> return true; >>>>>> >>>>>> return false; >>>>>> ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: rt2x00 regression 2021-09-29 8:22 ` Exuvo @ 2021-10-01 6:56 ` Kalle Valo 2021-11-05 13:25 ` Thorsten Leemhuis 0 siblings, 1 reply; 20+ messages in thread From: Kalle Valo @ 2021-10-01 6:56 UTC (permalink / raw) To: Exuvo; +Cc: Stanislaw Gruszka, linux-wireless, Helmut Schaa, regressions (adding regressions list for easier tracking) Exuvo <exuvo@exuvo.se> writes: > I would like to get this resolved, is there any more information you need from me? > > I have been manually patching this all year with: > > drivers/net/wireless/ralink/rt2x00/rt2x00usb.c > - if (rt2x00dev->num_proto_errs > 8) > - return true; > > It seems to just be some part of rt2800_load_firmware that is not > supported on my device and generating errors but it has been running > without problems in AP mode with daily usage. [...] >>>>>>> This most likely is the problem introduced by commit: >>>>>>> >>>>>>> commit e383c70474db32b9d4a3de6dfbd08784d19e6751 >>>>>>> Author: Stanislaw Gruszka <sgruszka@redhat.com> >>>>>>> Date: Tue Mar 12 10:51:42 2019 +0100 >>>>>>> >>>>>>> rt2x00: check number of EPROTO errors >>>>>>> >>>>>>> Plase check below patch that increase number of EPROTO checks >>>>>>> before marking device removed. If it does not help, plese >>>>>>> check if reverting above commits helps. Should we do a revert? Can someone submit that including an explanation of the regression. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: rt2x00 regression 2021-10-01 6:56 ` Kalle Valo @ 2021-11-05 13:25 ` Thorsten Leemhuis 2021-11-08 18:00 ` Thorsten Leemhuis 0 siblings, 1 reply; 20+ messages in thread From: Thorsten Leemhuis @ 2021-11-05 13:25 UTC (permalink / raw) To: Stanislaw Gruszka Cc: linux-wireless, Helmut Schaa, regressions, Kalle Valo, Exuvo Lo, this is your Linux kernel regression tracker speaking. On 01.10.21 08:56, Kalle Valo wrote: > (adding regressions list for easier tracking) Thx for this, that's how it got on the radar of regzbot, my Linux kernel regression tracking bot: https://linux-regtracking.leemhuis.info/regzbot/regression/87czop5j33.fsf@tynnyri.adurom.net/ > Exuvo <exuvo@exuvo.se> writes: > >> I would like to get this resolved, is there any more information you need from me? >> >> I have been manually patching this all year with: >> >> drivers/net/wireless/ralink/rt2x00/rt2x00usb.c >> - if (rt2x00dev->num_proto_errs > 8) >> - return true; >> >> It seems to just be some part of rt2800_load_firmware that is not >> supported on my device and generating errors but it has been running >> without problems in AP mode with daily usage. > > [...] > >>>>>>>> This most likely is the problem introduced by commit: >>>>>>>> >>>>>>>> commit e383c70474db32b9d4a3de6dfbd08784d19e6751 >>>>>>>> Author: Stanislaw Gruszka <sgruszka@redhat.com> >>>>>>>> Date: Tue Mar 12 10:51:42 2019 +0100 >>>>>>>> >>>>>>>> rt2x00: check number of EPROTO errors >>>>>>>> >>>>>>>> Plase check below patch that increase number of EPROTO checks >>>>>>>> before marking device removed. If it does not help, plese >>>>>>>> check if reverting above commits helps. > > Should we do a revert? Can someone submit that including an explanation > of the regression. Afaics nothing happened since then. Or did I miss anything? How can we get the ball rolling again? Stanislaw, is there anything Exuvo (who offered to help afaics) could test to get us closer to a fix? Ciao, Thorsten P.S.: I have no personal interest in this issue and watch it using regzbot. Hence, feel free to exclude me on further messages in this thread after the first reply, as I'm only posting this mail to hopefully get a status update and things rolling again. #regzbot poke ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: rt2x00 regression 2021-11-05 13:25 ` Thorsten Leemhuis @ 2021-11-08 18:00 ` Thorsten Leemhuis [not found] ` <20211109073127.ga109212@wp.pl> 2021-11-09 7:31 ` Stanislaw Gruszka 0 siblings, 2 replies; 20+ messages in thread From: Thorsten Leemhuis @ 2021-11-08 18:00 UTC (permalink / raw) To: Stanislaw Gruszka, Stanislaw Gruszka Cc: linux-wireless, Helmut Schaa, regressions, Kalle Valo, Exuvo Sending this again, but this time also to Stanislaw's email address currently found in MAINTAINERS. Stanislaw, can you help with this regression? Helmut: or can you help somehow to get things rolling again? Ciao, Thorsten, your Linux kernel regression tracker On 05.11.21 14:25, Thorsten Leemhuis wrote: > Lo, this is your Linux kernel regression tracker speaking. > > On 01.10.21 08:56, Kalle Valo wrote: >> (adding regressions list for easier tracking) > > Thx for this, that's how it got on the radar of regzbot, my Linux kernel > regression tracking bot: > https://linux-regtracking.leemhuis.info/regzbot/regression/87czop5j33.fsf@tynnyri.adurom.net/ > > >> Exuvo <exuvo@exuvo.se> writes: >> >>> I would like to get this resolved, is there any more information you need from me? >>> >>> I have been manually patching this all year with: >>> >>> drivers/net/wireless/ralink/rt2x00/rt2x00usb.c >>> - if (rt2x00dev->num_proto_errs > 8) >>> - return true; >>> >>> It seems to just be some part of rt2800_load_firmware that is not >>> supported on my device and generating errors but it has been running >>> without problems in AP mode with daily usage. >> >> [...] >> >>>>>>>>> This most likely is the problem introduced by commit: >>>>>>>>> >>>>>>>>> commit e383c70474db32b9d4a3de6dfbd08784d19e6751 >>>>>>>>> Author: Stanislaw Gruszka <sgruszka@redhat.com> >>>>>>>>> Date: Tue Mar 12 10:51:42 2019 +0100 >>>>>>>>> >>>>>>>>> rt2x00: check number of EPROTO errors >>>>>>>>> >>>>>>>>> Plase check below patch that increase number of EPROTO checks >>>>>>>>> before marking device removed. If it does not help, plese >>>>>>>>> check if reverting above commits helps. >> >> Should we do a revert? Can someone submit that including an explanation >> of the regression. > > Afaics nothing happened since then. Or did I miss anything? How can we > get the ball rolling again? > > Stanislaw, is there anything Exuvo (who offered to help afaics) could > test to get us closer to a fix? > > Ciao, Thorsten > > P.S.: I have no personal interest in this issue and watch it using > regzbot. Hence, feel free to exclude me on further messages in this > thread after the first reply, as I'm only posting this mail to hopefully > get a status update and things rolling again. #regzbot poke ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <20211109073127.ga109212@wp.pl>]
* Re: rt2x00 regression 2021-11-08 18:00 ` Thorsten Leemhuis [not found] ` <20211109073127.ga109212@wp.pl> @ 2021-11-09 7:31 ` Stanislaw Gruszka 2021-11-09 12:07 ` Stanislaw Gruszka 1 sibling, 1 reply; 20+ messages in thread From: Stanislaw Gruszka @ 2021-11-09 7:31 UTC (permalink / raw) To: Thorsten Leemhuis Cc: Stanislaw Gruszka, linux-wireless, Helmut Schaa, regressions, Kalle Valo, Exuvo On Mon, Nov 08, 2021 at 07:00:20PM +0100, Thorsten Leemhuis wrote: > Sending this again, but this time also to Stanislaw's email address > currently found in MAINTAINERS. > > Stanislaw, can you help with this regression? Yes. I'll check on mail archives what is the status and what can be done. Stanislaw > Helmut: or can you help somehow to get things rolling again? > > Ciao, Thorsten, your Linux kernel regression tracker > > On 05.11.21 14:25, Thorsten Leemhuis wrote: > > Lo, this is your Linux kernel regression tracker speaking. > > > > On 01.10.21 08:56, Kalle Valo wrote: > >> (adding regressions list for easier tracking) > > > > Thx for this, that's how it got on the radar of regzbot, my Linux kernel > > regression tracking bot: > > https://linux-regtracking.leemhuis.info/regzbot/regression/87czop5j33.fsf@tynnyri.adurom.net/ > > > > > >> Exuvo <exuvo@exuvo.se> writes: > >> > >>> I would like to get this resolved, is there any more information you need from me? > >>> > >>> I have been manually patching this all year with: > >>> > >>> drivers/net/wireless/ralink/rt2x00/rt2x00usb.c > >>> - if (rt2x00dev->num_proto_errs > 8) > >>> - return true; > >>> > >>> It seems to just be some part of rt2800_load_firmware that is not > >>> supported on my device and generating errors but it has been running > >>> without problems in AP mode with daily usage. > >> > >> [...] > >> > >>>>>>>>> This most likely is the problem introduced by commit: > >>>>>>>>> > >>>>>>>>> commit e383c70474db32b9d4a3de6dfbd08784d19e6751 > >>>>>>>>> Author: Stanislaw Gruszka <sgruszka@redhat.com> > >>>>>>>>> Date: Tue Mar 12 10:51:42 2019 +0100 > >>>>>>>>> > >>>>>>>>> rt2x00: check number of EPROTO errors > >>>>>>>>> > >>>>>>>>> Plase check below patch that increase number of EPROTO checks > >>>>>>>>> before marking device removed. If it does not help, plese > >>>>>>>>> check if reverting above commits helps. > >> > >> Should we do a revert? Can someone submit that including an explanation > >> of the regression. > > > > Afaics nothing happened since then. Or did I miss anything? How can we > > get the ball rolling again? > > > > Stanislaw, is there anything Exuvo (who offered to help afaics) could > > test to get us closer to a fix? > > > > Ciao, Thorsten > > > > P.S.: I have no personal interest in this issue and watch it using > > regzbot. Hence, feel free to exclude me on further messages in this > > thread after the first reply, as I'm only posting this mail to hopefully > > get a status update and things rolling again. > > #regzbot poke ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: rt2x00 regression 2021-11-09 7:31 ` Stanislaw Gruszka @ 2021-11-09 12:07 ` Stanislaw Gruszka 2021-11-09 15:22 ` Exuvo 0 siblings, 1 reply; 20+ messages in thread From: Stanislaw Gruszka @ 2021-11-09 12:07 UTC (permalink / raw) To: Thorsten Leemhuis Cc: Stanislaw Gruszka, linux-wireless, Helmut Schaa, regressions, Kalle Valo, Exuvo On Tue, Nov 09, 2021 at 08:32:07AM +0100, Stanislaw Gruszka wrote: > On Mon, Nov 08, 2021 at 07:00:20PM +0100, Thorsten Leemhuis wrote: > > Sending this again, but this time also to Stanislaw's email address > > currently found in MAINTAINERS. > > > > Stanislaw, can you help with this regression? > > Yes. > > I'll check on mail archives what is the status and what can be done. Ok, so what I can see here https://lore.kernel.org/linux-wireless/20211109073127.GA109212@wp.pl/T/#m6a677995c1afaf6b9b1ff19de9566f304089d3ac is that this problem happen only on firmware load, so I think we can use below patch as fix. Anton, please test it. Thanks Stanislaw diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c index e4473a551241..57c947dad036 100644 --- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c @@ -30,7 +30,8 @@ static bool rt2x00usb_check_usb_error(struct rt2x00_dev *rt2x00dev, int status) else rt2x00dev->num_proto_errs = 0; - if (rt2x00dev->num_proto_errs > 3) + if (rt2x00dev->num_proto_errs > 3 && + !test_bit(DEVICE_STATE_STARTED, &rt2x00dev->flags)) return true; return false; ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: rt2x00 regression 2021-11-09 12:07 ` Stanislaw Gruszka @ 2021-11-09 15:22 ` Exuvo [not found] ` <cc85b4e8a038417b865069c6578acf50@grupawp.pl> 0 siblings, 1 reply; 20+ messages in thread From: Exuvo @ 2021-11-09 15:22 UTC (permalink / raw) To: Stanislaw Gruszka, Thorsten Leemhuis Cc: Stanislaw Gruszka, linux-wireless, Helmut Schaa, regressions, Kalle Valo Just tested it and it passes the rt2x00lib_load_firmware but still errors on rt2800usb_set_device_state: [ 348.363942] ieee80211 phy1: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin' [ 348.364519] ieee80211 phy1: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.36 [ 348.650321] ieee80211 phy1: rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x0404 with error -71 [ 349.695576] ieee80211 phy1: rt2800_wait_csr_ready: Error - Unstable hardware [ 349.695606] ieee80211 phy1: rt2800usb_set_device_state: Error - Device failed to enter state 4 (-5) which was the last error i got in my previous dump_stack too (which you linked): 2020-07-15T19:16:10.956602+0000 kernel: Call Trace: 2020-07-15T19:16:10.956620+0000 kernel: dump_stack+0x64/0x88 2020-07-15T19:16:10.956635+0000 kernel: rt2x00usb_vendor_request.cold+0x2b/0x69 [rt2x00usb] 2020-07-15T19:16:10.956649+0000 kernel: rt2x00usb_vendor_req_buff_lock+0xa6/0x230 [rt2x00usb] 2020-07-15T19:16:10.956663+0000 kernel: rt2x00usb_register_write_lock+0x37/0x60 [rt2800usb] 2020-07-15T19:16:10.956677+0000 kernel: rt2800_mcu_request+0x100/0x110 [rt2800lib] 2020-07-15T19:16:10.956696+0000 kernel: rt2800_enable_radio+0xb6/0x2d36 [rt2800lib] 2020-07-15T19:16:10.956712+0000 kernel: rt2800usb_set_device_state+0xbd/0x18b [rt2800usb] 2020-07-15T19:16:10.956735+0000 kernel: rt2x00lib_enable_radio+0x3e/0xa0 [rt2x00lib] 2020-07-15T19:16:10.956754+0000 kernel: rt2x00lib_start+0x7c/0xc0 [rt2x00lib] 2020-07-15T19:16:10.956778+0000 kernel: drv_start+0x3e/0x130 [mac80211] Anton "exuvo" Olsson exuvo@exuvo.se On 2021-11-09 13:07, Stanislaw Gruszka wrote: > On Tue, Nov 09, 2021 at 08:32:07AM +0100, Stanislaw Gruszka wrote: >> On Mon, Nov 08, 2021 at 07:00:20PM +0100, Thorsten Leemhuis wrote: >>> Sending this again, but this time also to Stanislaw's email address >>> currently found in MAINTAINERS. >>> >>> Stanislaw, can you help with this regression? >> Yes. >> >> I'll check on mail archives what is the status and what can be done. > Ok, so what I can see here > https://lore.kernel.org/linux-wireless/20211109073127.GA109212@wp.pl/T/#m6a677995c1afaf6b9b1ff19de9566f304089d3ac > is that this problem happen only on firmware load, > so I think we can use below patch as fix. > > Anton, please test it. > > Thanks > Stanislaw > > diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c > index e4473a551241..57c947dad036 100644 > --- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c > +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c > @@ -30,7 +30,8 @@ static bool rt2x00usb_check_usb_error(struct rt2x00_dev *rt2x00dev, int status) > else > rt2x00dev->num_proto_errs = 0; > > - if (rt2x00dev->num_proto_errs > 3) > + if (rt2x00dev->num_proto_errs > 3 && > + !test_bit(DEVICE_STATE_STARTED, &rt2x00dev->flags)) > return true; > > return false; ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <cc85b4e8a038417b865069c6578acf50@grupawp.pl>]
* Re: rt2x00 regression [not found] ` <cc85b4e8a038417b865069c6578acf50@grupawp.pl> @ 2021-11-10 6:59 ` Kalle Valo 2021-11-10 8:01 ` Stanislaw Gruszka 0 siblings, 1 reply; 20+ messages in thread From: Kalle Valo @ 2021-11-10 6:59 UTC (permalink / raw) To: Stanisław Gruszka Cc: Exuvo, Thorsten Leemhuis, Stanislaw Gruszka, linux-wireless, Helmut Schaa, regressions Stanisław Gruszka <stf_xl@wp.pl> writes: > Dnia 9 listopada 2021 16:22 Exuvo <exuvo@exuvo.se> napisał(a): > > Just tested it and it passes the rt2x00lib_load_firmware but still errors on > rt2800usb_set_device_state: > > <snip> > > @@ -30,7 +30,8 @@ static bool rt2x00usb_check_usb_error(struct rt2x00_dev *rt2x00dev, int status) > else > rt2x00dev->num_proto_errs = 0; > > - if (rt2x00dev->num_proto_errs > 3) > + if (rt2x00dev->num_proto_errs > 3 && > + !test_bit(DEVICE_STATE_STARTED, &rt2x00dev->flags)) > return true; > > return false; > > Sorry, I screwed logic in my patch. It should be test_bit() instead of !test_bit(). > And also we should not count when device did not start. So patch should be somewhat different. I'll > send tomorrow hopefully better patch. No HTML, please :) I'll reply so that lists see your email. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: rt2x00 regression 2021-11-10 6:59 ` Kalle Valo @ 2021-11-10 8:01 ` Stanislaw Gruszka 2021-11-11 10:54 ` Exuvo 0 siblings, 1 reply; 20+ messages in thread From: Stanislaw Gruszka @ 2021-11-10 8:01 UTC (permalink / raw) To: Kalle Valo Cc: Exuvo, Thorsten Leemhuis, Stanislaw Gruszka, linux-wireless, Helmut Schaa, regressions On Wed, Nov 10, 2021 at 08:59:22AM +0200, Kalle Valo wrote: > Stanisław Gruszka <stf_xl@wp.pl> writes: > > > Dnia 9 listopada 2021 16:22 Exuvo <exuvo@exuvo.se> napisał(a): > > > > Just tested it and it passes the rt2x00lib_load_firmware but still errors on > > rt2800usb_set_device_state: > > > > <snip> > > > > @@ -30,7 +30,8 @@ static bool rt2x00usb_check_usb_error(struct rt2x00_dev *rt2x00dev, int status) > > else > > rt2x00dev->num_proto_errs = 0; > > > > - if (rt2x00dev->num_proto_errs > 3) > > + if (rt2x00dev->num_proto_errs > 3 && > > + !test_bit(DEVICE_STATE_STARTED, &rt2x00dev->flags)) > > return true; > > > > return false; > > > > Sorry, I screwed logic in my patch. It should be test_bit() instead of !test_bit(). > > And also we should not count when device did not start. So patch should be somewhat different. I'll > > send tomorrow hopefully better patch. > > No HTML, please :) I'll reply so that lists see your email. Eh, I sent from my phone to give quick update, did not realize it send in HTML. Anyway, below is updated patch. I hope it will work correctly now. Regards Stanislaw diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c index e4473a551241..74c3d8cb3100 100644 --- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c @@ -25,6 +25,9 @@ static bool rt2x00usb_check_usb_error(struct rt2x00_dev *rt2x00dev, int status) if (status == -ENODEV || status == -ENOENT) return true; + if (!test_bit(DEVICE_STATE_STARTED, &rt2x00dev->flags)) + return false; + if (status == -EPROTO || status == -ETIMEDOUT) rt2x00dev->num_proto_errs++; else ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: rt2x00 regression 2021-11-10 8:01 ` Stanislaw Gruszka @ 2021-11-11 10:54 ` Exuvo 2021-11-11 14:10 ` [PATCH] rt2x00: do not mark device gone on EPROTO errors during start Stanislaw Gruszka 0 siblings, 1 reply; 20+ messages in thread From: Exuvo @ 2021-11-11 10:54 UTC (permalink / raw) To: Stanislaw Gruszka, Kalle Valo Cc: Thorsten Leemhuis, Stanislaw Gruszka, linux-wireless, Helmut Schaa, regressions Yes that patch works :D Anton "exuvo" Olsson exuvo@exuvo.se On 2021-11-10 09:01, Stanislaw Gruszka wrote: > On Wed, Nov 10, 2021 at 08:59:22AM +0200, Kalle Valo wrote: >> Stanisław Gruszka <stf_xl@wp.pl> writes: >> >>> Dnia 9 listopada 2021 16:22 Exuvo <exuvo@exuvo.se> napisał(a): >>> >>> Just tested it and it passes the rt2x00lib_load_firmware but still errors on >>> rt2800usb_set_device_state: >>> >>> <snip> >>> >>> @@ -30,7 +30,8 @@ static bool rt2x00usb_check_usb_error(struct rt2x00_dev *rt2x00dev, int status) >>> else >>> rt2x00dev->num_proto_errs = 0; >>> >>> - if (rt2x00dev->num_proto_errs > 3) >>> + if (rt2x00dev->num_proto_errs > 3 && >>> + !test_bit(DEVICE_STATE_STARTED, &rt2x00dev->flags)) >>> return true; >>> >>> return false; >>> >>> Sorry, I screwed logic in my patch. It should be test_bit() instead of !test_bit(). >>> And also we should not count when device did not start. So patch should be somewhat different. I'll >>> send tomorrow hopefully better patch. >> No HTML, please :) I'll reply so that lists see your email. > Eh, I sent from my phone to give quick update, did not realize > it send in HTML. > > Anyway, below is updated patch. I hope it will work correctly now. > > Regards > Stanislaw > > diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c > index e4473a551241..74c3d8cb3100 100644 > --- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c > +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c > @@ -25,6 +25,9 @@ static bool rt2x00usb_check_usb_error(struct rt2x00_dev *rt2x00dev, int status) > if (status == -ENODEV || status == -ENOENT) > return true; > > + if (!test_bit(DEVICE_STATE_STARTED, &rt2x00dev->flags)) > + return false; > + > if (status == -EPROTO || status == -ETIMEDOUT) > rt2x00dev->num_proto_errs++; > else > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH] rt2x00: do not mark device gone on EPROTO errors during start 2021-11-11 10:54 ` Exuvo @ 2021-11-11 14:10 ` Stanislaw Gruszka 2021-11-18 6:16 ` Thorsten Leemhuis 2021-11-29 10:54 ` Kalle Valo 0 siblings, 2 replies; 20+ messages in thread From: Stanislaw Gruszka @ 2021-11-11 14:10 UTC (permalink / raw) To: Exuvo Cc: Kalle Valo, Thorsten Leemhuis, Stanislaw Gruszka, linux-wireless, Helmut Schaa, regressions As reported by Exuvo is possible that we have lot's of EPROTO errors during device start i.e. firmware load. But after that device works correctly. Hence marking device gone by few EPROTO errors done by commit e383c70474db ("rt2x00: check number of EPROTO errors") caused regression - Exuvo device stop working after kernel update. To fix disable the check during device start. Reported-and-tested-by: Exuvo <exuvo@exuvo.se> Fixes: e383c70474db ("rt2x00: check number of EPROTO errors") Cc: stable@vger.kernel.org Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl> --- drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c index e4473a551241..74c3d8cb3100 100644 --- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c @@ -25,6 +25,9 @@ static bool rt2x00usb_check_usb_error(struct rt2x00_dev *rt2x00dev, int status) if (status == -ENODEV || status == -ENOENT) return true; + if (!test_bit(DEVICE_STATE_STARTED, &rt2x00dev->flags)) + return false; + if (status == -EPROTO || status == -ETIMEDOUT) rt2x00dev->num_proto_errs++; else -- 2.25.4 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH] rt2x00: do not mark device gone on EPROTO errors during start 2021-11-11 14:10 ` [PATCH] rt2x00: do not mark device gone on EPROTO errors during start Stanislaw Gruszka @ 2021-11-18 6:16 ` Thorsten Leemhuis 2021-11-19 14:19 ` Kalle Valo 2021-11-29 10:54 ` Kalle Valo 1 sibling, 1 reply; 20+ messages in thread From: Thorsten Leemhuis @ 2021-11-18 6:16 UTC (permalink / raw) To: Stanislaw Gruszka, Exuvo Cc: Kalle Valo, Stanislaw Gruszka, linux-wireless, Helmut Schaa, regressions Hi, this is your Linux kernel regression tracker speaking. Thx for this fix. On 11.11.21 15:10, Stanislaw Gruszka wrote: > As reported by Exuvo is possible that we have lot's of EPROTO errors > during device start i.e. firmware load. But after that device works > correctly. Hence marking device gone by few EPROTO errors done by > commit e383c70474db ("rt2x00: check number of EPROTO errors") caused > regression - Exuvo device stop working after kernel update. To fix > disable the check during device start. > > Reported-and-tested-by: Exuvo <exuvo@exuvo.se> FWIW: In case you need to send an improved patch, could you please add this before the 'Reported-by:' (see at (¹) below for the reasoning): Link: https://lore.kernel.org/linux-wireless/bff7d309-a816-6a75-51b6-5928ef4f7a8c@exuvo.se/ And if the patch is already good to go: could the subsystem maintainer please add it when applying? > Fixes: e383c70474db ("rt2x00: check number of EPROTO errors") What's the plan to getting this merged? Just wondering, because there *afaics* wasn't any activity for a week now. Yes, e383c70474db was a commit for v5.2-rc1, so it's not a new regression that needs to be handled really urgently. But it's still a regression that would be good to get fixed rather sooner than later, as there might be still people out there then might run into this on a update. Ciao, Thorsten (carrying his Linux kernel regression tracker hat) (¹) Long story: The commit message would benefit from a link to the regression report, for reasons explained in Documentation/process/submitting-patches.rst. To quote: ``` If related discussions or any other background information behind the change can be found on the web, add 'Link:' tags pointing to it. In case your patch fixes a bug, for example, add a tag with a URL referencing the report in the mailing list archives or a bug tracker; [...] ``` This concept is old, but the text was reworked recently to make this use case for the Link: tag clearer. For details see: https://git.kernel.org/linus/1f57bd42b77c Yes, that "Link:" is not really crucial; but it's good to have if someone needs to look into the backstory of this change sometime in the future. But I care for a different reason. I'm tracking this regression (and others) with regzbot, my Linux kernel regression tracking bot. This bot will notice if a patch with a Link: tag to a tracked regression gets posted and record that, which allowed anyone looking into the regression to quickly gasp the current status from regzbot's webui (https://linux-regtracking.leemhuis.info/regzbot ) or its reports. The bot will also notice if a commit with a Link: tag to a regression report is applied by Linus and then automatically mark the regression as resolved then. IOW: this tag makes my life a regression tracker a lot easier, as I otherwise have to tell regzbot manually when the fix lands. :-/ P.S.: As a Linux kernel regression tracker I'm getting a lot of reports on my table. I can only look briefly into most of them. Unfortunately therefore I sometimes will get things wrong or miss something important. I hope that's not the case here; if you think it is, don't hesitate to tell me about it in a public reply. That's in everyone's interest, as what I wrote above might be misleading to everyone reading this; any suggestion I gave they thus might sent someone reading this down the wrong rabbit hole, which none of us wants. BTW, I have no personal interest in this issue, which is tracked using regzbot, my Linux kernel regression tracking bot (https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting this mail to get things rolling again and hence don't need to be CC on all further activitie wrt to this regression. Ohh, and feel free to ignore the following lines, they are meant for regzbot: #regzbot poke > Cc: stable@vger.kernel.org > Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl> > --- > drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c > index e4473a551241..74c3d8cb3100 100644 > --- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c > +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c > @@ -25,6 +25,9 @@ static bool rt2x00usb_check_usb_error(struct rt2x00_dev *rt2x00dev, int status) > if (status == -ENODEV || status == -ENOENT) > return true; > > + if (!test_bit(DEVICE_STATE_STARTED, &rt2x00dev->flags)) > + return false; > + > if (status == -EPROTO || status == -ETIMEDOUT) > rt2x00dev->num_proto_errs++; > else > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] rt2x00: do not mark device gone on EPROTO errors during start 2021-11-18 6:16 ` Thorsten Leemhuis @ 2021-11-19 14:19 ` Kalle Valo 0 siblings, 0 replies; 20+ messages in thread From: Kalle Valo @ 2021-11-19 14:19 UTC (permalink / raw) To: Thorsten Leemhuis Cc: Stanislaw Gruszka, Exuvo, Stanislaw Gruszka, linux-wireless, Helmut Schaa, regressions Thorsten Leemhuis <regressions@leemhuis.info> writes: > Hi, this is your Linux kernel regression tracker speaking. Thx for this fix. > > On 11.11.21 15:10, Stanislaw Gruszka wrote: >> As reported by Exuvo is possible that we have lot's of EPROTO errors >> during device start i.e. firmware load. But after that device works >> correctly. Hence marking device gone by few EPROTO errors done by >> commit e383c70474db ("rt2x00: check number of EPROTO errors") caused >> regression - Exuvo device stop working after kernel update. To fix >> disable the check during device start. >> >> Reported-and-tested-by: Exuvo <exuvo@exuvo.se> > > FWIW: In case you need to send an improved patch, could you > please add this before the 'Reported-by:' (see at (¹) below for the > reasoning): > > Link: > https://lore.kernel.org/linux-wireless/bff7d309-a816-6a75-51b6-5928ef4f7a8c@exuvo.se/ > > And if the patch is already good to go: could the subsystem maintainer > please add it when applying? Sure, I'll add it during commit. >> Fixes: e383c70474db ("rt2x00: check number of EPROTO errors") > > What's the plan to getting this merged? My plan is to commit this to wireless-drivers tree, the tree was just closed due to the merge window. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: rt2x00: do not mark device gone on EPROTO errors during start 2021-11-11 14:10 ` [PATCH] rt2x00: do not mark device gone on EPROTO errors during start Stanislaw Gruszka 2021-11-18 6:16 ` Thorsten Leemhuis @ 2021-11-29 10:54 ` Kalle Valo 1 sibling, 0 replies; 20+ messages in thread From: Kalle Valo @ 2021-11-29 10:54 UTC (permalink / raw) To: Stanislaw Gruszka Cc: Exuvo, Thorsten Leemhuis, Stanislaw Gruszka, linux-wireless, Helmut Schaa, regressions Stanislaw Gruszka <stf_xl@wp.pl> wrote: > As reported by Exuvo is possible that we have lot's of EPROTO errors > during device start i.e. firmware load. But after that device works > correctly. Hence marking device gone by few EPROTO errors done by > commit e383c70474db ("rt2x00: check number of EPROTO errors") caused > regression - Exuvo device stop working after kernel update. To fix > disable the check during device start. > > Link: https://lore.kernel.org/linux-wireless/bff7d309-a816-6a75-51b6-5928ef4f7a8c@exuvo.se/ > Reported-and-tested-by: Exuvo <exuvo@exuvo.se> > Fixes: e383c70474db ("rt2x00: check number of EPROTO errors") > Cc: stable@vger.kernel.org > Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl> Patch applied to wireless-drivers.git, thanks. ed53ae756930 rt2x00: do not mark device gone on EPROTO errors during start -- https://patchwork.kernel.org/project/linux-wireless/patch/20211111141003.GA134627@wp.pl/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <ca+gwt0b5syrznglqwqoeujk4cwmvc=dkawre9vn8kqc6kbzkgw@mail.gmail.com>]
end of thread, other threads:[~2021-11-29 10:56 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-09-26 16:32 rt2x00 regression Anton Olsson 2019-09-27 8:03 ` Stanislaw Gruszka [not found] ` <CA+GwT0B5SyRZnGLqwqOeuJK4CWMVc=dKaWre9VN8KQC6kBzKGw@mail.gmail.com> 2019-12-03 7:57 ` Stanislaw Gruszka 2019-12-03 18:50 ` Anton Olsson 2020-04-05 4:58 ` Anton Olsson 2020-07-15 19:47 ` Anton Olsson 2021-09-29 8:22 ` Exuvo 2021-10-01 6:56 ` Kalle Valo 2021-11-05 13:25 ` Thorsten Leemhuis 2021-11-08 18:00 ` Thorsten Leemhuis [not found] ` <20211109073127.ga109212@wp.pl> 2021-11-09 7:31 ` Stanislaw Gruszka 2021-11-09 12:07 ` Stanislaw Gruszka 2021-11-09 15:22 ` Exuvo [not found] ` <cc85b4e8a038417b865069c6578acf50@grupawp.pl> 2021-11-10 6:59 ` Kalle Valo 2021-11-10 8:01 ` Stanislaw Gruszka 2021-11-11 10:54 ` Exuvo 2021-11-11 14:10 ` [PATCH] rt2x00: do not mark device gone on EPROTO errors during start Stanislaw Gruszka 2021-11-18 6:16 ` Thorsten Leemhuis 2021-11-19 14:19 ` Kalle Valo 2021-11-29 10:54 ` Kalle Valo [not found] <ca+gwt0b5syrznglqwqoeujk4cwmvc=dkawre9vn8kqc6kbzkgw@mail.gmail.com>
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).