Received-SPF: pass (google.com: domain of linux-wireless+bounces-6359-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
From: Ping-Ke Shih <pkshih@realtek.com>
To: Lewis Robbins <lewis.robbins2@gmail.com>,
        "kvalo@kernel.org"
	<kvalo@kernel.org>
CC: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: RE: [PATCH] wifi: rtw88: reduce failed to flush queue severity
Thread-Topic: [PATCH] wifi: rtw88: reduce failed to flush queue severity
Thread-Index: AQHajfcTVqg9i2byzkGmq7L8YOsC/LFojyVQgAD1gD3///KZAIAAvNSw
Date: Tue, 16 Apr 2024 02:57:57 +0000
Message-ID: <d03e8c066a6e464aa61badb252c32b01@realtek.com>
References: <87le5ey52e.fsf@kernel.org>
 <20240415232837.388945-2-lewis.robbins2@gmail.com>
In-Reply-To: <20240415232837.388945-2-lewis.robbins2@gmail.com>
Accept-Language: en-US, zh-TW
Content-Language: zh-TW
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
MIME-Version: 1.0

Lewis Robbins <lewis.robbins2@gmail.com> wrote:
>=20
> Ping-Ke Shih <pkshih@realtek.com> writes:
>=20
> > Lewis Robbins <lewis.robbins2@gmail.com> wrote:
> >>
> >> Reduce the log message severity when we fail to flush device priority
> >> queue. If a system has a lot of traffic, we may fail to flush the queu=
e
> >> in time. This generates a lot of messages in the kernel ring buffer. A=
s
> >> this is a common occurrence, we should use dev_info instead of dev_war=
n.
> >>
> >> Signed-off-by: Lewis Robbins <lewis.robbins2@gmail.com>
> >
> > Acked-by: Ping-Ke Shih <pkshih@realtek.com>
> >
> > I'd like to know situations of " If a system has a lot of traffic...".
> > Did you scan or do something during traffic?
>=20
> So, after digging a bit more, it seems you're right this only happens dur=
ing a
> scan. The log message itself is repeated about 5-10x.

That is the same as my test before.=20

>=20
> I'm not sure as to the cause. If the flush operation takes a long time do=
 we
> need to release any mutexes etc? And if this is just a hardware issue, th=
en we
> can do a debug print as you say.

The cause is because packets in hardware TX queue that can't be sent out in=
 time,
and flush ops with 'drop =3D false', so driver throws one warning. I don't =
have
good idea for now. Maybe, we can add a special debug mask to replace this k=
ind of
verbose warning with uncertain solution.=20