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@xxxxxxxxxxxxxx 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 |
