Received-SPF: pass (google.com: domain of linux-wireless+bounces-8429-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> <CA+GA0_tUy0EuXm0CGYa8SsS78oRNHUanBNwRf_BLXERa1=MYdg@mail.gmail.com>
 <b9c85972ab634364bf8a705a4f4513fd@realtek.com>
In-Reply-To: <b9c85972ab634364bf8a705a4f4513fd@realtek.com>
From: =?UTF-8?Q?Marcin_=C5=9Alusarz?= <marcin.slusarz@gmail.com>
Date: Mon, 3 Jun 2024 16:52:39 +0200
Message-ID: <CA+GA0_v1rpoFrRVxpKpYqOrjdxEecn_m3+RKwxYc9H761dpMvw@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

czw., 30 maj 2024 o 05:13 Ping-Ke Shih <pkshih@realtek.com> napisa=C5=82(a)=
:
>
> Marcin =C5=9Alusarz <marcin.slusarz@gmail.com> wrote:
> > =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 s=
equence 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 at=
tached 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 dow=
n).
> > >
> > > 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 c=
an be easy
> > > to understand how it works. Not prefer adjusting existing flags to im=
plicitly
> > > have behavior you want.
> >
> > So, do you think this is a chip issue, not just some driver misconfigur=
ation?
>
> I asked internal USB WiFi people who say vendor drivers of USB/SDIO can't
> power-on/-off frequently but not very sure if hardware issue or driver is=
sue.
>
> >
> > 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->sta=
rted) in
> > ieee80211_rx_napi (in wireless-next, the code was moved to ieee80211_rx=
_list).
> >
> > With my patch, I checked and hit that WARN_ON, too, but very occasional=
ly.
> >
> > I think the difference is in what happens in rtw_ips_enter - I disabled=
 only
> > the power_off, but you also disabled everything else, including the can=
celation
> > 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?
> >
>
> I forgot to say my patch is compiled test only, and I didn't consider flo=
w
> too much, just to close the behavior of your patches. You can improve my =
patch
> to be more reliable to avoid WARN_ON().

Two variants of the patch that fix this issue will follow. They are
built on top of yours
v2 and my "wifi: rtw88: schedule rx work after everything is set up"
from the other thread.
Please choose the one you like more :).