Received-SPF: pass (google.com: domain of linux-wireless+bounces-8199-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240527173454.459264-1-marcin.slusarz@gmail.com>
 <0f1aef25-2b91-408d-aca9-9943dc9367b3@gmail.com> <CA+GA0_vz7S++ttaug2kGZWyzyc-PMZoVSsiSH-sXn4uctX5V2A@mail.gmail.com>
 <fdb30dac-4ab3-4182-80b2-8dc197420778@gmail.com>
In-Reply-To: <fdb30dac-4ab3-4182-80b2-8dc197420778@gmail.com>
From: =?UTF-8?Q?Marcin_=C5=9Alusarz?= <marcin.slusarz@gmail.com>
Date: Tue, 28 May 2024 14:38:00 +0200
Message-ID: <CA+GA0_tJxv_4vuoRssbXnYtDD2Z-AizyoiSjvT=EW7DnyJRQwQ@mail.gmail.com>
Subject: Re: wifi: rtw88: 8821CU hangs after some number of power-off/on cycles
To: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Cc: linux-wireless@vger.kernel.org, =?UTF-8?Q?Marcin_=C5=9Alusarz?= <mslusarz@renau.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

wt., 28 maj 2024 o 14:25 Bitterblue Smith <rtl8821cerfe2@gmail.com> napisa=
=C5=82(a):
>
> On 28/05/2024 13:42, Marcin =C5=9Alusarz wrote:
> > pon., 27 maj 2024 o 20:43 Bitterblue Smith <rtl8821cerfe2@gmail.com> na=
pisa=C5=82(a):
> >>
> >> On 27/05/2024 20:34, Marcin =C5=9Alusarz wrote:
> >>> From: Marcin =C5=9Alusarz <mslusarz@renau.com>
> >>>
> >>> If I don't connect to any Wifi network, after around 10 minutes, the =
device
> >>> hangs with endless spamming of:
> >>> rtw_8821cu 1-1:1.2: rtw_usb_reg_sec: reg 0x4e0, usb write 1 fail, sta=
tus: -71
> >>> killing both Wifi and Bluetooth part of the device.
> >>>
> >>> On arm, just leaving the wifi device unconnected kills it in up to 20=
 minutes.
> >>> If I keep restarting wpa_supplicant I can trigger it within a minute.
> >>> Looping "ifconfig wlan0 down; ifconfig wlan0 up" also triggers it wit=
hin a minute.
> >>>
> >>> On x86_64 system the only way I could trigger this was via ifconfig l=
oop,
> >>> but it took 3 hours and 20 minutes to do it.
> >>>
> >>> The only thing that can "fix" the device is replugging it.
> >>>
> >>> I found out that the reason for those hangs is a power-off+on sequenc=
e that's
> >>> triggered by the above steps.
> >>>
> >>> Disabling power-off for that chip "fixes" the issue. The patches belo=
w
> >>> implement that, but I'm not seriously proposing them for merging.
> >>>
> >>> Marcin =C5=9Alusarz (2):
> >>>   wifi: rtw88: use RTW_FLAG_RUNNING for deciding whether to enter/lea=
ve
> >>>     IPS
> >>>   wifi: rtw88: disable power offs for 8821C
> >>>
> >>>  drivers/net/wireless/realtek/rtw88/main.c | 14 ++++++++------
> >>>  drivers/net/wireless/realtek/rtw88/ps.c   |  4 ++--
> >>>  2 files changed, 10 insertions(+), 8 deletions(-)
> >>>
> >>
> >> The first patch alone doesn't fix it?
> >
> > The first patch exists only to make the second patch work.
> > Without the first one, rtw_enter_ips will perform all actions except ac=
tually
> > doing the power off, which clears the POWERON flag.
> > After that, rtw_leave_ips will happily return early success without act=
ually
> > undoing the stuff that rtw_enter_ips did (like canceling all work_struc=
ts).
>
> I see.
>
> I wonder if it's really the chip that has a problem, or rtw88?
> Can you try your ifconfig loop with the other driver?
> https://github.com/morrownr/8821cu-20210916/

Actually, the issue was found on this driver. I started looking at the issu=
e
more closely (and discovered the exact reproduction steps) after I switched
to rtw88 and discovered it has exactly the same problem.

So yeah, it's either a chip issue or the same bug in both drivers.