Re: rtw_8822ce wifi regression after kernel update from 5.15 to 5.16

[Larry Finger <Larry.Finger@lwfinger.net>]

On 2/28/22 08:30, Thorsten Leemhuis wrote:
> Hi, this is your Linux kernel regression tracker. Top-posting for once,
> to make this easily accessible to everyone.
> 
> Yan-Hsuan Chuang, sorry, I failed to notice that you didn't get the
> regression report below. Could you take a look what's wrong there?
> 
> BTW: Nico, did you try another bisection? And is the problem still
> happening? Did you maybe give 5.17-rc a shot to check if the problem
> still happens there?
> 
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> 
> P.S.: As the Linux kernel's regression tracker I'm getting a lot of
> reports on my table. I can only look briefly into most of them and lack
> knowledge about most of the areas they concern. I thus unfortunately
> will sometimes 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
> in a public reply, it's in everyone's interest to set the public record
> straight.
> 
> #regzbot poke
> 
> On 15.02.22 09:25, Thorsten Leemhuis wrote:
>> [...]
>> On 14.02.22 20:25, Nico Sneck wrote:
>>> Hi,
>>>
>>> I'm running Fedora 35 on a Huawei Matestation S (HUAWEI PUM-WDX9), AMD
>>> Renoir with Realtek rtw_8822ce handling wifi stuff.
>>>
>>> Ever since the kernel update from 5.15.13-200.fc35 to 5.16.8-200.fc35
>>> (which I performed Feb 12th), I noticed that my Wifi connection
>>> doesn't really work anymore. I'm connecting to a Zyxel VMG3927-B50A,
>>> and it appears to be using 5 GHz connection always. I also tested that
>>> 5.17-rc4 also suffers from this issue.
>>>
>>> The issue is that even trying to ping my routers gateway address will
>>> result in connection timeouts, and ping times are in the thousands to
>>> tens of thousands of milliseconds (normally peak ping times are ~3-6
>>> ms), making wireless unusable with 5.16+.
>>> I can also see that in dmesg logs there are two types of rtw_8822ce
>>> driver warnings flooding the logs, which I didn't see with 5.15:
>>>
>>> "helmi 13 18:20:03 fedora kernel: rtw_8822ce 0000:06:00.0: timed out
>>> to flush queue {1,2}"
>>> "helmi 13 18:16:23 fedora kernel: rtw_8822ce 0000:06:00.0: failed to
>>> get tx report from firmware"
>>>
>>> Some stats:
>>> On kernel 5.15.13-200.fc35 running for 29 days:
>>> [nico@fedora ~]$ journalctl -k -b -18 | grep 'timed out to flush queue' | wc -l
>>> 0
>>>
>>> [nico@fedora ~]$ journalctl -k -b -18 | grep 'failed to get tx report
>>> from firmware' | wc -l
>>> 0
>>>
>>> On kernel 5.16.8-200.fc35 running for 4 hours:
>>> [nico@fedora ~]$ journalctl -k -b -17 | grep 'timed out to flush queue' | wc -l
>>> 45370
>>>
>>> [nico@fedora ~]$ journalctl -k -b -17 | grep 'failed to get tx report
>>> from firmware' | wc -l
>>> 502
>>>
>>> I tried bisecting which commit introduced this regression, but after
>>> some 12 hours of recompiling and testing, it seems like I failed
>>> somehow. I tried a bisect with first known good revision as
>>> 8bb7eca972ad (5.15 release commit), and first known bad revision as
>>> df0cc57e057f (5.16 release commit). I managed to identify that
>>> revision
>>> fc02cb2b37fe Merge tag 'net-next-for-5.16' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
>>> is bad, but then all other revisions were good apart from
>>> 8a33dcc2f6d5 (refs/bisect/bad) Merge
>>> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
>>> which was also bad.
>>> But here's the baffling part, commit 6b278c0cb378 was good, and it's
>>> the last commit in the merge (8a33dcc2f6d5) which appeared bad.
>>> Now I retested with 8a33dcc2f6d5, and I don't see the issues anymore,
>>> so I guess I tested a wrong kernel version at that point or something.
>>> shrug.
>>>
>>> So I can only assume that the regression came in one of the commits inside
>>> fc02cb2b37fe Merge tag 'net-next-for-5.16' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
>>> but it'll take me a while to be try bisecting the commits in that merge again.
>>>
>>> If anyone has any idea about what could cause these issues I'm seeing,
>>> I can try out patches / test different things. But I'll try
>>> rebisecting this again soon.

Nico,

Your use of rtw_8822ce in the title finally registered on me. With that driver 
in use, that means that you are using my GitHub repo; however, newer kernels 
have the driver built in, but with names such as rtw88_8822ce. The difference in 
the name is deliberate. If you want to use the GitHub version, you must 
blacklist the ones from the kernel.

To check this, run 'lsmod | grep 88'. If you see a mixture of rtw_xxx and 
rtw88_xxx, then this is your problem.

Larry