Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230108211324.442823-1-martin.blumenstingl@googlemail.com>
 <20230108211324.442823-2-martin.blumenstingl@googlemail.com> <20230331125906.GF15436@pengutronix.de>
In-Reply-To: <20230331125906.GF15436@pengutronix.de>
From:   Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date:   Sat, 1 Apr 2023 23:30:40 +0200
Message-ID: <CAFBinCB8B4-oYaFY4p-20_PCWh_6peq75O9JjV6ZusVXPKSaDw@mail.gmail.com>
Subject: Re: [PATCH v3 1/3] wifi: rtw88: Move register access from
 rtw_bf_assoc() outside the RCU
To:     Sascha Hauer <s.hauer@pengutronix.de>
Cc:     linux-wireless@vger.kernel.org, tony0620emma@gmail.com,
        kvalo@kernel.org, pkshih@realtek.com, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        Jernej Skrabec <jernej.skrabec@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi Sascha,

On Fri, Mar 31, 2023 at 2:59=E2=80=AFPM Sascha Hauer <s.hauer@pengutronix.d=
e> wrote:
>
> On Sun, Jan 08, 2023 at 10:13:22PM +0100, Martin Blumenstingl wrote:
> > USB and (upcoming) SDIO support may sleep in the read/write handlers.
> > Shrink the RCU critical section so it only cover the call to
> > ieee80211_find_sta() and finding the ic_vht_cap/vht_cap based on the
> > found station. This moves the chip's BFEE configuration outside the
> > rcu_read_lock section and thus prevent "scheduling while atomic" or
> > "Voluntary context switch within RCU read-side critical section!"
> > warnings when accessing the registers using an SDIO card (which is
> > where this issue has been spotted in the real world - but it also
> > affects USB cards).
>
> Unfortunately this introduces a regression on my RTW8821CU chip. With
> this it constantly looses connection to the AP and reconnects shortly
> after:
Sorry to hear this! This is odd and unfortunately I don't understand
the reason for this.
rtw_bf_assoc() is only called from
drivers/net/wireless/realtek/rtw88/mac80211.c with rtwdev->mutex held.
So I don't think that it's a race condition.

There's a module parameter which lets you enable/disable BF support:
$ git grep rtw_bf_support drivers/net/wireless/realtek/rtw88/ | grep param
drivers/net/wireless/realtek/rtw88/main.c:module_param_named(support_bf,
rtw_bf_support, bool, 0644);

Have you tried disabling BF support?
Also +Cc Jernej in case he has an idea.


Best regards,
Martin