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
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On Tue, 2022-05-31 at 09:42 +0200, [email protected] 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, [email protected] 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
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On Fri, 2022-06-10 at 15:26 +0200, [email protected] 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, [email protected] 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
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |