Received-SPF: pass (google.com: domain of linux-wireless+bounces-8270-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <20240527173454.459264-1-marcin.slusarz@gmail.com>
 <9bfc8f01e99b43e485b2afc6ae4fd661@realtek.com> <CA+GA0_sQ_Bnp8CUq1Pmxf7zut1Kocaxbw4iXT4hYC5_ceXb7WQ@mail.gmail.com>
 <3cc9cc75468d487c988dbacd8dfc5f57@realtek.com>
In-Reply-To: <3cc9cc75468d487c988dbacd8dfc5f57@realtek.com>
From: =?UTF-8?Q?Marcin_=C5=9Alusarz?= <marcin.slusarz@gmail.com>
Date: Wed, 29 May 2024 17:53:39 +0200
Message-ID: <CA+GA0_tUy0EuXm0CGYa8SsS78oRNHUanBNwRf_BLXERa1=MYdg@mail.gmail.com>
Subject: Re: wifi: rtw88: 8821CU hangs after some number of power-off/on cycles
To: Ping-Ke Shih <pkshih@realtek.com>
Cc: "linux-wireless@vger.kernel.org" <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

=C5=9Br., 29 maj 2024 o 03:52 Ping-Ke Shih <pkshih@realtek.com> napisa=C5=
=82(a):
>
> Marcin =C5=9Alusarz <marcin.slusarz@gmail.com> wrote:
> > wt., 28 maj 2024 o 05:52 Ping-Ke Shih <pkshih@realtek.com> napisa=C5=82=
(a):
> > >
> > > Marcin =C5=9Alusarz <marcin.slusarz@gmail.com> wrote:
> > > >
> > > > I found out that the reason for those hangs is a power-off+on seque=
nce that's
> > > > triggered by the above steps.
> > >
> > > To avoid power-off/on sequence once device becomes idle, I would like=
 to add
> > > a ips_disabled helper. Please revert your changes and apply my attach=
ed patch.
> >
> > My first attempt was very similar, and it fixed some cases but not all =
of them.
> >
> > This is due to the existence of a second source of power-offs - rtw_ops=
_stop,
> > which is called, e.g., on downing the interface (ifconfig wlan0 down).
>
> Please try attached v2 patch. I would like to have an explicit helper
> (i.e. always_power_on in v2) to have this fix, so days later people can b=
e easy
> to understand how it works. Not prefer adjusting existing flags to implic=
itly
> have behavior you want.

So, do you think this is a chip issue, not just some driver misconfiguratio=
n?

I'm asking because if we are going in this direction, there's something
more to fix... With your v2, very frequently, I hit WARN_ON(!local->started=
) in
ieee80211_rx_napi (in wireless-next, the code was moved to ieee80211_rx_lis=
t).

With my patch, I checked and hit that WARN_ON, too, but very occasionally.

I think the difference is in what happens in rtw_ips_enter - I disabled onl=
y
the power_off, but you also disabled everything else, including the cancela=
tion
of work_structs.

The warning itself sounds harmless, but I think users should never see such
warnings, so this needs to be fixed somehow. Probably some additional
work_struct(s) need to be canceled?

Marcin