Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <16885654-09f0-c139-cc9b-c6c4d666932e@quicinc.com>
Date:   Tue, 25 Jul 2023 14:47:14 +0530
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.12.0
Subject: Re: Fwd: ath11k: QCN9074: ce desc not available for wmi command
To:     Linux regressions mailing list <regressions@lists.linux.dev>,
        "Bagas Sanjaya" <bagasdotme@gmail.com>,
        Kalle Valo <quic_kvalo@quicinc.com>,
        "Johannes Berg" <johannes@sipsolutions.net>,
        Jakub Kicinski <kuba@kernel.org>
CC:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        "Linux Atheros 11K" <ath11k@lists.infradead.org>
References: <1326a6e4-758d-3344-d90c-8a126748b034@gmail.com>
 <6a0c3aa0-86a8-8c06-81df-2d7085946cf5@leemhuis.info>
Content-Language: en-US
From:   Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
In-Reply-To: <6a0c3aa0-86a8-8c06-81df-2d7085946cf5@leemhuis.info>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

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