| Message ID | 20220530135457.1104091-11-s.hauer@pengutronix.de (mailing list archive) |
|---|---|
| State | Awaiting Upstream |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | RTW88: Add support for USB variants | expand |
| Context | Check | Description |
|---|---|---|
| netdev/tree_selection | success | Not a local patch |
On Mon, 2022-05-30 at 15:54 +0200, Sascha Hauer wrote: > The powersave modes do not work with USB devices (tested with a > RTW8822CU) properly. With powersave modes enabled the driver issues > messages like: > > rtw_8822cu 1-1:1.2: firmware failed to leave lps state > rtw_8822cu 1-1:1.2: timed out to flush queue 3 Could you try module parameter rtw_disable_lps_deep_mode=1 to see if it can work? If it works, I suggest to apply below code: diff --git a/main.c b/main.c index 3f7a5d54..3bb07898 100644 --- a/main.c +++ b/main.c @@ -1345,6 +1345,9 @@ static enum rtw_lps_deep_mode rtw_update_lps_deep_mode(struct rtw_dev *rtwdev, { struct rtw_chip_info *chip = rtwdev->chip; + if (rtw_hci_type(rtwdev) == RTW_HCI_TYPE_USB) + return LPS_DEEP_MODE_NONE; + if (rtw_disable_lps_deep_mode || !chip->lps_deep_mode_supported || !fw->feature) return LPS_DEEP_MODE_NONE; -- Ping-Ke
On Tue, May 31, 2022 at 01:07:36AM +0000, Ping-Ke Shih wrote: > On Mon, 2022-05-30 at 15:54 +0200, Sascha Hauer wrote: > > The powersave modes do not work with USB devices (tested with a > > RTW8822CU) properly. With powersave modes enabled the driver issues > > messages like: > > > > rtw_8822cu 1-1:1.2: firmware failed to leave lps state > > rtw_8822cu 1-1:1.2: timed out to flush queue 3 > > Could you try module parameter rtw_disable_lps_deep_mode=1 to see > if it can work? No, this module parameter doesn't seem to make any difference. # cat /sys/module/rtw88_core/parameters/disable_lps_deep Y Still "firmware failed to leave lps state" and poor performance. Any other ideas what may go wrong here? Sascha
On Tue, 2022-05-31 at 09:42 +0200, s.hauer@pengutronix.de wrote: > On Tue, May 31, 2022 at 01:07:36AM +0000, Ping-Ke Shih wrote: > > On Mon, 2022-05-30 at 15:54 +0200, Sascha Hauer wrote: > > > The powersave modes do not work with USB devices (tested with a > > > RTW8822CU) properly. With powersave modes enabled the driver issues > > > messages like: > > > > > > rtw_8822cu 1-1:1.2: firmware failed to leave lps state > > > rtw_8822cu 1-1:1.2: timed out to flush queue 3 > > > > Could you try module parameter rtw_disable_lps_deep_mode=1 to see > > if it can work? > > No, this module parameter doesn't seem to make any difference. > > # cat /sys/module/rtw88_core/parameters/disable_lps_deep > Y > > Still "firmware failed to leave lps state" and poor performance. > > Any other ideas what may go wrong here? > Today, I borrow a 8822cu, and use your patchset but revert patch 10/10 to reproduce this issue. With firmware 7.3.0, it looks bad. After checking something about firmware, I found the firmware is old, so upgrade to 9.9.11, and then it works well for 10 minutes, no abnormal messages. Please try if it also works to you. Ping-Ke
On Thu, Jun 09, 2022 at 12:51:49PM +0000, Ping-Ke Shih wrote: > On Tue, 2022-05-31 at 09:42 +0200, s.hauer@pengutronix.de wrote: > > On Tue, May 31, 2022 at 01:07:36AM +0000, Ping-Ke Shih wrote: > > > On Mon, 2022-05-30 at 15:54 +0200, Sascha Hauer wrote: > > > > The powersave modes do not work with USB devices (tested with a > > > > RTW8822CU) properly. With powersave modes enabled the driver issues > > > > messages like: > > > > > > > > rtw_8822cu 1-1:1.2: firmware failed to leave lps state > > > > rtw_8822cu 1-1:1.2: timed out to flush queue 3 > > > > > > Could you try module parameter rtw_disable_lps_deep_mode=1 to see > > > if it can work? > > > > No, this module parameter doesn't seem to make any difference. > > > > # cat /sys/module/rtw88_core/parameters/disable_lps_deep > > Y > > > > Still "firmware failed to leave lps state" and poor performance. > > > > Any other ideas what may go wrong here? > > > > Today, I borrow a 8822cu, and use your patchset but revert > patch 10/10 to reproduce this issue. With firmware 7.3.0, > it looks bad. After checking something about firmware, I > found the firmware is old, so upgrade to 9.9.11, and then > it works well for 10 minutes, no abnormal messages. I originally used firmware 5.0.0. Then I have tried 9.9.6 I have lying around here from my distro. That version behaves like the old 5.0.0 version. Finally I switched to 9.9.11 from current linux-firmware repository. That doesn't work at all for me unfortunately: [ 221.076279] rtw_8822cu 2-1:1.2: Firmware version 9.9.11, H2C version 15 [ 221.078405] rtw_8822cu 2-1:1.2: Firmware version 9.9.4, H2C version 15 [ 239.783261] wlan0: authenticate with 76:83:c2:ce:83:0b [ 242.398435] wlan0: send auth to 76:83:c2:ce:83:0b (try 1/3) [ 242.402992] wlan0: authenticated [ 242.420735] wlan0: associate with 76:83:c2:ce:83:0b (try 1/3) [ 242.437094] wlan0: RX AssocResp from 76:83:c2:ce:83:0b (capab=0x1411 status=0 aid=4) [ 242.485521] wlan0: associated [ 242.564847] wlan0: Connection to AP 76:83:c2:ce:83:0b lost [ 244.577617] wlan0: authenticate with 76:83:c2:cd:83:0b [ 244.578257] wlan0: bad VHT capabilities, disabling VHT [ 246.866182] wlan0: send auth to 76:83:c2:cd:83:0b (try 1/3) [ 246.871830] wlan0: authenticated [ 246.892754] wlan0: associate with 76:83:c2:cd:83:0b (try 1/3) [ 246.911045] wlan0: RX AssocResp from 76:83:c2:cd:83:0b (capab=0x1431 status=0 aid=3) [ 246.940608] wlan0: associated [ 247.152308] wlan0: Connection to AP 76:83:c2:cd:83:0b lost [ 248.912821] wlan0: Connection to AP 00:00:00:00:00:00 lost [ 249.105517] wlan0: authenticate with 76:83:c2:ce:83:0b [ 251.482183] wlan0: send auth to 76:83:c2:ce:83:0b (try 1/3) [ 251.486765] wlan0: authenticated [ 251.508731] wlan0: associate with 76:83:c2:ce:83:0b (try 1/3) [ 251.521904] wlan0: RX AssocResp from 76:83:c2:ce:83:0b (capab=0x1411 status=0 aid=4) [ 251.565233] wlan0: associated [ 251.720602] wlan0: Connection to AP 76:83:c2:ce:83:0b lost [ 253.527904] wlan0: Connection to AP 00:00:00:00:00:00 lost [ 253.728243] wlan0: authenticate with 76:83:c2:cd:83:0b [ 253.728921] wlan0: bad VHT capabilities, disabling VHT [ 256.014184] wlan0: send auth to 76:83:c2:cd:83:0b (try 1/3) [ 256.019608] wlan0: authenticated [ 256.044702] wlan0: associate with 76:83:c2:cd:83:0b (try 1/3) [ 256.062049] wlan0: RX AssocResp from 76:83:c2:cd:83:0b (capab=0x1431 status=0 aid=3) [ 256.093117] wlan0: associated [ 256.169071] wlan0: Connection to AP 76:83:c2:cd:83:0b lost [ 258.145286] wlan0: authenticate with 76:83:c2:ce:83:0b [ 260.626182] wlan0: send auth to 76:83:c2:ce:83:0b (try 1/3) [ 260.630495] wlan0: authenticated [ 260.652783] wlan0: associate with 76:83:c2:ce:83:0b (try 1/3) [ 260.666201] wlan0: RX AssocResp from 76:83:c2:ce:83:0b (capab=0x1411 status=0 aid=4) [ 260.708596] wlan0: associated [ 260.769613] wlan0: Connection to AP 76:83:c2:ce:83:0b lost [ 262.770668] wlan0: authenticate with 76:83:c2:cd:83:0b [ 262.771272] wlan0: bad VHT capabilities, disabling VHT [ 265.158184] wlan0: send auth to 76:83:c2:cd:83:0b (try 1/3) This goes on forever. I finally tried 9.9.10 and 9.9.9, they also behave like 9.9.11. No luck today :( Sascha
On Fri, 2022-06-10 at 15:26 +0200, s.hauer@pengutronix.de wrote: > On Thu, Jun 09, 2022 at 12:51:49PM +0000, Ping-Ke Shih wrote: > > > > Today, I borrow a 8822cu, and use your patchset but revert > > patch 10/10 to reproduce this issue. With firmware 7.3.0, > > it looks bad. After checking something about firmware, I > > found the firmware is old, so upgrade to 9.9.11, and then > > it works well for 10 minutes, no abnormal messages. > > I originally used firmware 5.0.0. Then I have tried 9.9.6 I have lying > around here from my distro. That version behaves like the old 5.0.0 > version. Finally I switched to 9.9.11 from current linux-firmware > repository. That doesn't work at all for me unfortunately: > > [ 221.076279] rtw_8822cu 2-1:1.2: Firmware version 9.9.11, H2C version 15 > [ 221.078405] rtw_8822cu 2-1:1.2: Firmware version 9.9.4, H2C version 15 > [ 239.783261] wlan0: authenticate with 76:83:c2:ce:83:0b > [ 242.398435] wlan0: send auth to 76:83:c2:ce:83:0b (try 1/3) > [ 242.402992] wlan0: authenticated > [ 242.420735] wlan0: associate with 76:83:c2:ce:83:0b (try 1/3) > [ 242.437094] wlan0: RX AssocResp from 76:83:c2:ce:83:0b (capab=0x1411 status=0 aid=4) > [ 242.485521] wlan0: associated > [ 242.564847] wlan0: Connection to AP 76:83:c2:ce:83:0b lost > [ 244.577617] wlan0: authenticate with 76:83:c2:cd:83:0b > [ 244.578257] wlan0: bad VHT capabilities, disabling VHT > > This goes on forever. I finally tried 9.9.10 and 9.9.9, they also behave > like 9.9.11. > Please help do more experiements on your 8822cu with the latest firmware 9.9.11. 1. which module RFE type you are using? My 8822cu is RFE type 4. Get this information from cat /sys/kernel/debug/ieee80211/phyXXX/rtw88/coex_info The 4th line: Mech/ RFE = Non-Shared/ 4 4. Disable power save to see if it still disconnect from AP iw wlan0 set power_save off If this can work well, still power save mode works abnormal. 3. Disable keep-alive. (with power_save on) --- a/main.c +++ b/main.c @@ -2199,6 +2199,7 @@ int rtw_register_hw(struct rtw_dev *rtwdev, struct ieee80211_hw *hw) ieee80211_hw_set(hw, HAS_RATE_CONTROL); ieee80211_hw_set(hw, TX_AMSDU); ieee80211_hw_set(hw, SINGLE_SCAN_ON_ALL_BANDS); + ieee80211_hw_set(hw, CONNECTION_MONITOR); This can make it still connected even it doesn't receive anything. Check if it can leave power save without abnormal messages. 4. USB interference Very low possibility, but simply try USB 2.0 and 3.0 ports. 5. Try another AP working on different band (2.4GHz or 5Ghz) I wise these can narrow down the problem you met. Ping-Ke
On Mon, Jun 13, 2022 at 12:02:23AM +0000, Ping-Ke Shih wrote: > On Fri, 2022-06-10 at 15:26 +0200, s.hauer@pengutronix.de wrote: > > On Thu, Jun 09, 2022 at 12:51:49PM +0000, Ping-Ke Shih wrote: > > > > > > Today, I borrow a 8822cu, and use your patchset but revert > > > patch 10/10 to reproduce this issue. With firmware 7.3.0, > > > it looks bad. After checking something about firmware, I > > > found the firmware is old, so upgrade to 9.9.11, and then > > > it works well for 10 minutes, no abnormal messages. > > > > I originally used firmware 5.0.0. Then I have tried 9.9.6 I have lying > > around here from my distro. That version behaves like the old 5.0.0 > > version. Finally I switched to 9.9.11 from current linux-firmware > > repository. That doesn't work at all for me unfortunately: > > > > [ 221.076279] rtw_8822cu 2-1:1.2: Firmware version 9.9.11, H2C version 15 > > [ 221.078405] rtw_8822cu 2-1:1.2: Firmware version 9.9.4, H2C version 15 > > [ 239.783261] wlan0: authenticate with 76:83:c2:ce:83:0b > > [ 242.398435] wlan0: send auth to 76:83:c2:ce:83:0b (try 1/3) > > [ 242.402992] wlan0: authenticated > > [ 242.420735] wlan0: associate with 76:83:c2:ce:83:0b (try 1/3) > > [ 242.437094] wlan0: RX AssocResp from 76:83:c2:ce:83:0b (capab=0x1411 status=0 aid=4) > > [ 242.485521] wlan0: associated > > [ 242.564847] wlan0: Connection to AP 76:83:c2:ce:83:0b lost > > [ 244.577617] wlan0: authenticate with 76:83:c2:cd:83:0b > > [ 244.578257] wlan0: bad VHT capabilities, disabling VHT > > > > This goes on forever. I finally tried 9.9.10 and 9.9.9, they also behave > > like 9.9.11. > > > > Please help do more experiements on your 8822cu with the > latest firmware 9.9.11. > > 1. which module RFE type you are using? > My 8822cu is RFE type 4. > Get this information from > > cat /sys/kernel/debug/ieee80211/phyXXX/rtw88/coex_info > > The 4th line: > Mech/ RFE = Non-Shared/ 4 I have: Mech/ RFE = Shared/ 3 As you mention this I remember that I added this hunk to rtw8822c.c: @@ -4895,6 +4916,8 @@ static const struct rtw_rfe_def rtw8822c_rfe_defs[] = { [0] = RTW_DEF_RFE(8822c, 0, 0), [1] = RTW_DEF_RFE(8822c, 0, 0), [2] = RTW_DEF_RFE(8822c, 0, 0), + [3] = RTW_DEF_RFE(8822c, 0, 0), + [4] = RTW_DEF_RFE(8822c, 0, 0), [5] = RTW_DEF_RFE(8822c, 0, 5), [6] = RTW_DEF_RFE(8822c, 0, 0), }; I copied [4] from Hans Ulli Krolls repository, but the [3] entry needed for my hardware I made up myself. I don't know if that's correct and what difference it makes, but I stopped thinking about it when I realized that it works. > > 4. Disable power save to see if it still disconnect from AP > > iw wlan0 set power_save off > > If this can work well, still power save mode works abnormal. With powersave disabled it still doesn't work. > > 3. Disable keep-alive. (with power_save on) > > --- a/main.c > +++ b/main.c > @@ -2199,6 +2199,7 @@ int rtw_register_hw(struct rtw_dev *rtwdev, struct ieee80211_hw *hw) > ieee80211_hw_set(hw, HAS_RATE_CONTROL); > ieee80211_hw_set(hw, TX_AMSDU); > ieee80211_hw_set(hw, SINGLE_SCAN_ON_ALL_BANDS); > + ieee80211_hw_set(hw, CONNECTION_MONITOR); > > This can make it still connected even it doesn't receive anything. > Check if it can leave power save without abnormal messages. > > 4. USB interference > > Very low possibility, but simply try USB 2.0 and 3.0 ports. Surprisingly this really makes a difference. I have a EHCI port which I used up to now. One other port is behind a XHCI controller and on that port the device behaves much better, but still far from perfect. > > 5. Try another AP working on different band (2.4GHz or 5Ghz) I have tried two access points in both 2.4GHt and 5GHz bands. That doesn't make any significant difference. Some other things I saw yesterday during testing: I've seen this more than once: [ 249.914750] rtw_8822cu 4-1:1.2: error beacon valid [ 249.914890] rtw_8822cu 4-1:1.2: Download probe request to firmware failed [ 249.914903] rtw_8822cu 4-1:1.2: Update probe request failed [ 249.925005] rtw_8822cu 4-1:1.2: HW scan failed with status: -16 [ 251.246244] rtw_8822cu 4-1:1.2: error beacon valid [ 251.246387] rtw_8822cu 4-1:1.2: Download probe request to firmware failed [ 251.246400] rtw_8822cu 4-1:1.2: Update probe request failed [ 251.255539] rtw_8822cu 4-1:1.2: HW scan failed with status: -16 [ 262.611263] rtw_8822cu 4-1:1.2: error beacon valid With powersave enabled I saw this while pinging the device from a remote host: 64 bytes from 192.168.0.196: icmp_seq=304 ttl=64 time=169 ms 64 bytes from 192.168.0.196: icmp_seq=305 ttl=64 time=15405 ms 64 bytes from 192.168.0.196: icmp_seq=306 ttl=64 time=14395 ms 64 bytes from 192.168.0.196: icmp_seq=307 ttl=64 time=13371 ms 64 bytes from 192.168.0.196: icmp_seq=310 ttl=64 time=10300 ms 64 bytes from 192.168.0.196: icmp_seq=311 ttl=64 time=9276 ms 64 bytes from 192.168.0.196: icmp_seq=312 ttl=64 time=8252 ms 64 bytes from 192.168.0.196: icmp_seq=313 ttl=64 time=7229 ms 64 bytes from 192.168.0.196: icmp_seq=314 ttl=64 time=6205 ms 64 bytes from 192.168.0.196: icmp_seq=315 ttl=64 time=5181 ms 64 bytes from 192.168.0.196: icmp_seq=316 ttl=64 time=4154 ms 64 bytes from 192.168.0.196: icmp_seq=317 ttl=64 time=3130 ms 64 bytes from 192.168.0.196: icmp_seq=318 ttl=64 time=2110 ms 64 bytes from 192.168.0.196: icmp_seq=319 ttl=64 time=1087 ms 64 bytes from 192.168.0.196: icmp_seq=320 ttl=64 time=63.8 ms You see that we have a 16s lag and then all of a sudden the answer to 16 ping packets come in at once. This all looks very erratic now. I would be grateful for hints where I could look at. In the meantime I see if I get get another rtl8822cu wifi dongle to see if my hardware is bad. Sascha
diff --git a/drivers/net/wireless/realtek/rtw88/mac80211.c b/drivers/net/wireless/realtek/rtw88/mac80211.c index 3c07485d6ba47..fb5faf3bf1eed 100644 --- a/drivers/net/wireless/realtek/rtw88/mac80211.c +++ b/drivers/net/wireless/realtek/rtw88/mac80211.c @@ -89,7 +89,8 @@ static int rtw_ops_config(struct ieee80211_hw *hw, u32 changed) } if (changed & IEEE80211_CONF_CHANGE_PS) { - if (hw->conf.flags & IEEE80211_CONF_PS) { + if (hw->conf.flags & IEEE80211_CONF_PS && + rtw_hci_type(rtwdev) != RTW_HCI_TYPE_USB) { rtwdev->ps_enabled = true; } else { rtwdev->ps_enabled = false;
The powersave modes do not work with USB devices (tested with a RTW8822CU) properly. With powersave modes enabled the driver issues messages like: rtw_8822cu 1-1:1.2: firmware failed to leave lps state rtw_8822cu 1-1:1.2: timed out to flush queue 3 Also ping round trip times increase significantly from 1..2ms to 10..200ms. Until this has been resolved disable the powersave modes for USB devices. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> --- drivers/net/wireless/realtek/rtw88/mac80211.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)