Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
MIME-Version: 1.0
References: <CAO_iuKEL8tHnovpGiQGUxg7JUpZFxHpxhOHbqAMgbt5R4Eftgg@mail.gmail.com>
 <2d1c129b-d473-39e3-69b7-6f36dc1682a6@leemhuis.info> <9312eb18-840f-9a1f-bcb0-8e3a43e45239@leemhuis.info>
 <236d45a6-8b88-c02e-a61d-ce1773fdb0ef@lwfinger.net> <02ef7552-67f5-dbcf-ece6-87b5b49e1bb5@leemhuis.info>
 <CAO_iuKHQ2DdLvSegcoezCzRVHqNFg+HM8qk1fr1n=s9cMz8QFA@mail.gmail.com>
 <877d96xlbk.fsf@tynnyri.adurom.net> <023e90a9-01bf-4334-a69a-259705ffa55f@leemhuis.info>
In-Reply-To: <023e90a9-01bf-4334-a69a-259705ffa55f@leemhuis.info>
From:   Nico Sneck <snecknico@gmail.com>
Date:   Wed, 16 Mar 2022 19:50:13 +0200
Message-ID: <CAO_iuKG0gE=5fEKMF2A+iWUhsxtnPOQtTQTkBRo2vH5CmKu7iA@mail.gmail.com>
Subject: Re: rtw_8822ce wifi regression after kernel update from 5.15 to 5.16
To:     Thorsten Leemhuis <regressions@leemhuis.info>
Cc:     Kalle Valo <kvalo@kernel.org>,
        Larry Finger <Larry.Finger@lwfinger.net>,
        Yan-Hsuan Chuang <tony0620emma@gmail.com>,
        "regressions@lists.linux.dev" <regressions@lists.linux.dev>,
        linux-wireless@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi all,

On Wed, Mar 16, 2022 at 12:14 PM Thorsten Leemhuis
<regressions@leemhuis.info> wrote:
> FWIW, in the initial report Nico mentioned he tried to bisect the issue
> and there mentioned a few git commit id's which are from mainline, so it
> seems he tried mainline. But maybe there is some DKMS or akmod package
> that is interfering.

Indeed, I've reproduced this issue on mainline kernels, and also bisected
using the mainline kernel.
No DKMS or anything like that.

> Nico, it would help a lot if you could clarify the situation and maybe
> try another shot at a bisection.

Yeah, sorry for being slow to respond. These days I tend to run my personal
computer just on the weekends, thus this is a bit slow. Also, this issue is
hard to reproduce, usually it happens within a couple minutes after booting,
but I've actually now been running a vanilla 5.17-rc7 (commit: ea4424be1688)
for a day, and the issue just popped up.

So I can confirm, this issue is still present as of ea4424be1688
(soon-to-be 5.18).

This is how it appears when pinging my routers gateway address:
> 64 bytes from 192.168.10.1: icmp_seq=20846 ttl=64 time=29780 ms
> 64 bytes from 192.168.10.1: icmp_seq=20847 ttl=64 time=28771 ms
> 64 bytes from 192.168.10.1: icmp_seq=20848 ttl=64 time=27768 ms
> 64 bytes from 192.168.10.1: icmp_seq=20849 ttl=64 time=26763 ms
> 64 bytes from 192.168.10.1: icmp_seq=20850 ttl=64 time=25757 ms
> 64 bytes from 192.168.10.1: icmp_seq=20851 ttl=64 time=24752 ms
> 64 bytes from 192.168.10.1: icmp_seq=20852 ttl=64 time=23747 ms
> 64 bytes from 192.168.10.1: icmp_seq=20853 ttl=64 time=22742 ms
> 64 bytes from 192.168.10.1: icmp_seq=20854 ttl=64 time=21737 ms
> 64 bytes from 192.168.10.1: icmp_seq=20855 ttl=64 time=20734 ms
> 64 bytes from 192.168.10.1: icmp_seq=20874 ttl=64 time=1298 ms
> 64 bytes from 192.168.10.1: icmp_seq=20875 ttl=64 time=455 ms
> 64 bytes from 192.168.10.1: icmp_seq=20876 ttl=64 time=3128 ms
[...]
> From 192.168.10.107 icmp_seq=20925 Destination Host Unreachable
> From 192.168.10.107 icmp_seq=20926 Destination Host Unreachable
[...]
> ping: sendmsg: No buffer space available
> ping: sendmsg: No buffer space available
> ping: sendmsg: No buffer space available

At the same time dmesg is flooded with "timed out to flush queue"
and "failed to get tx report from firmware".

And just to reiterate; this does not happen on 5.15. Only 5.16 and up.

I'll kick off another round of bisecting now. Will probably take me at
least a week to follow up though. A lot depends on how fast this
issue pops up with each round of bisecting.