lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 25 Jul 2023 14:47:14 +0530
From:   Manikanta Pubbisetty <quic_mpubbise@...cinc.com>
To:     Linux regressions mailing list <regressions@...ts.linux.dev>,
        "Bagas Sanjaya" <bagasdotme@...il.com>,
        Kalle Valo <quic_kvalo@...cinc.com>,
        "Johannes Berg" <johannes@...solutions.net>,
        Jakub Kicinski <kuba@...nel.org>
CC:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Linux Atheros 11K" <ath11k@...ts.infradead.org>
Subject: Re: Fwd: ath11k: QCN9074: ce desc not available for wmi command

On 6/26/2023 6:19 PM, Linux regression tracking (Thorsten Leemhuis) wrote:
> Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
> for once, to make this easily accessible to everyone.
> 
> Hmmm, there afaics was no real progress and not even a single reply from
> a developer (neither here or in bugzilla) since the issue was reported
> ~10 days ago. :-/
> 
> Manikanta, did you maybe just miss that this is caused by change of
> yours (and thus is something you should look into)?
> 

Extremely sorry for having this missed due to incorrect mail filters on 
my machine. I have looked the logs attached to the buganizer.

The issue from the logs looks like it is happening during the boot.
Generally, issues like these "ce desc not available for wmi command" 
occur when there is no room in the copy engine pipe for driver to 
enqueue the command to the firmware and in many cases these would have 
happen when firmware is reaping the ring slowly.

It is puzzling to know that thread NAPI is causing this and reverting 
this got the issue fixed. NAPI generally acts on the RX rings and has 
nothing to do with the TX.

Hi Sanjay,

This issue is seen just with the kernel upgrade alone? Or firmware has 
also been upgraded?

Meanwhile, I'll try to repro the issue on my local setup and try to root 
cause the problem. Pls let me know the firmware version that has been 
used for testing.

Although I'm okay reverting the threaded NAPI patch for now, in the long 
run we want that back as threaded NAPI brings significant improvement on 
the throughput front.

Thanks,
Manikanta

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ