On 3/14/2025 12:14 AM, Johan Hovold wrote:
On Thu, Mar 13, 2025 at 09:31:56PM +0800, Miaoqing Pan wrote:
On 3/13/2025 12:43 AM, Johan Hovold wrote:
On Wed, Mar 12, 2025 at 09:11:45AM +0800, Miaoqing Pan wrote:
On 3/11/2025 11:20 PM, Jeff Johnson wrote:
That didn't answer Johan's first question:
Are there ever any valid reasons for seeing a zero-length descriptor?
The events currently observed are all firmware logs. The discarded
packets will not affect normal operation. I will adjust the logging to
debug level.
Have you looked at the device side of things as well? Could it be that
the firmware is doing something wrong when forwarding the logs?
How sure are you that you only see this with firmware logs?
Checked, no issues have been found so far.
I've taken a closer look at the driver and it seems like we're missing a
read barrier to make sure that the updated descriptor is not read until
after the head pointer.
Miaoqing, could you try the below patch with your reproducer and see if
it is enough to fix the corruption?
+ /* Make sure descriptor is read after the head pointer. */
+ dma_rmb();
+
*nbytes = ath11k_hal_ce_dst_status_get_length(desc);
if (*nbytes == 0) {
+ WARN_ON_ONCE(1); // FIXME: remove
ret = -EIO;
goto err;
}
This issue can still be reproduced.
[ 3283.687469] WARNING: CPU: 0 PID: 0 at
/drivers/net/wireless/ath/ath11k/ce.c:405
ath11k_ce_per_engine_service+0x228/0x3e4 [ath11k]
Thanks for verifying.
Which platform are you testing on and which kernel are you using?
I'm still waiting to hear back from some people testing my patch on the
X13s (sc8280xp).
Johan
qcs615-ride, kernel 6.6.65.
I think the hardware has already ensured synchronization between
descriptor and head pointer, which isn't difficult to achieve. The issue
is likely caused by something else and requires further debugging.
