All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@kernel.org>
To: Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
Cc: <ath11k@lists.infradead.org>,  <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH v3 0/3] Enable low power mode when WLAN is not active
Date: Thu, 08 Dec 2022 09:54:29 +0200	[thread overview]
Message-ID: <87y1ri1gay.fsf@kernel.org> (raw)
In-Reply-To: <2b0ac3c4-74e3-47f1-6aa7-72f2a4176824@quicinc.com> (Manikanta Pubbisetty's message of "Fri, 25 Nov 2022 09:59:33 +0530")

Manikanta Pubbisetty <quic_mpubbise@quicinc.com> writes:

> On 11/23/2022 9:35 PM, Kalle Valo wrote:
>
>> Kalle Valo <kvalo@kernel.org> writes:
>>
>>> Manikanta Pubbisetty <quic_mpubbise@quicinc.com> writes:
>>>
>>>> Currently, WLAN chip is powered once during driver probe and is kept
>>>> ON (powered) always even when WLAN is not active; keeping the chip
>>>> powered ON all the time will consume extra power which is not
>>>> desirable for battery operated devices. Same is the case with non-WoW
>>>> suspend, chip will not be put into low power mode when the system is
>>>> suspended resulting in higher battery drain.
>>>>
>>>> Send QMI MODE OFF command to firmware during WiFi OFF to put device
>>>> into low power mode.
>>>>
>>>> Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1
>>>> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.16
>>>>
>>>> Manikanta Pubbisetty (3):
>>>>    ath11k: Fix double free issue during SRNG deinit
>>>>    ath11k: Move hardware initialization logic to start()
>>>>    ath11k: Enable low power mode when WLAN is not active
>>>> ---
>>>> V3:
>>>>   - Removed patch "ath11k: Fix failed to parse regulatory event print" as it is not needed anymore
>>>>   - Fixed a potential deadlock scenario reported by lockdep around ab->core_lock with V2 changes
>>>>   - Fixed other minor issues that were found during code review
>>>>   - Spelling corrections in the commit messages
>>>
>>> I still see a crash, immediately after the first rmmod:
>>>
>>> Nov 22 11:05:47 nuc2  [  139.378719] rmmod ath11k_pci
>>> Nov 22 11:05:48 nuc2 [ 139.892395] general protection fault, probably
>>> for non-canonical address 0xdffffc000000003e: 0000 [#1] PREEMPT SMP
>>> DEBUG_PAGEALLOC KASAN
>>> Nov 22 11:05:48 nuc2 [ 139.892453] KASAN: null-ptr-deref in range
>>> [0x00000000000001f0-0x00000000000001f7]
>>>
>>> Really odd that you don't see it. Unfortunately not able to debug this
>>> further right now.
>>>
>>> This is with:
>>>
>>> wcn6855 hw2.0 WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.9
>>
>> A bit more information how I see the crash. So first I have all modules
>> loaded:
>>
>> $ lsmod
>> Module                  Size  Used by
>> ath11k_pci             57344  0
>> ath11k               2015232  1 ath11k_pci
>> mac80211             3284992  1 ath11k
>> libarc4                16384  1 mac80211
>> cfg80211             2494464  2 ath11k,mac80211
>> qmi_helpers            57344  1 ath11k
>> qrtr_mhi               20480  0
>> mhi                   217088  2 ath11k_pci,qrtr_mhi
>> qrtr                   98304  5 qrtr_mhi
>> nvme                  122880  3
>> nvme_core             299008  5 nvme
>> $
>>
>> Then I just remove ath11k_pci module and boom:
>>
>> $ sudo rmmod ath11k_pci
>>
>> [ 153.658409] general protection fault, probably for non-canonical
>> address 0xdffffc000000003e: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
>> KASAN
>>
>> This happens every time, there doesn't seem to be any randomness on the
>> behaviour.
>>
>
> Thanks for the help Kalle, this is exactly what I was doing in my
> tests. Unfortunately, I'm not able to reproduce the problem. I have
> also tried with the exact firmware that you have pointed out. Let me
> see if I'm missing anything.

I tested this more and patch 3 seems to be the one causing the crash. I
didn't see this when patch 1-2 were applied.

The crash happens in ath11k_dp_process_rxdma_err() in this line:

	srng = &ab->hal.srng_list[err_ring->ring_id];

ab looks sane to me (0xffff88814c960000) but err_ring is set to 0x200.
Does this help?

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

WARNING: multiple messages have this Message-ID (diff)
From: Kalle Valo <kvalo@kernel.org>
To: Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
Cc: <ath11k@lists.infradead.org>, <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH v3 0/3] Enable low power mode when WLAN is not active
Date: Thu, 08 Dec 2022 09:54:29 +0200	[thread overview]
Message-ID: <87y1ri1gay.fsf@kernel.org> (raw)
In-Reply-To: <2b0ac3c4-74e3-47f1-6aa7-72f2a4176824@quicinc.com> (Manikanta Pubbisetty's message of "Fri, 25 Nov 2022 09:59:33 +0530")

Manikanta Pubbisetty <quic_mpubbise@quicinc.com> writes:

> On 11/23/2022 9:35 PM, Kalle Valo wrote:
>
>> Kalle Valo <kvalo@kernel.org> writes:
>>
>>> Manikanta Pubbisetty <quic_mpubbise@quicinc.com> writes:
>>>
>>>> Currently, WLAN chip is powered once during driver probe and is kept
>>>> ON (powered) always even when WLAN is not active; keeping the chip
>>>> powered ON all the time will consume extra power which is not
>>>> desirable for battery operated devices. Same is the case with non-WoW
>>>> suspend, chip will not be put into low power mode when the system is
>>>> suspended resulting in higher battery drain.
>>>>
>>>> Send QMI MODE OFF command to firmware during WiFi OFF to put device
>>>> into low power mode.
>>>>
>>>> Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1
>>>> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.16
>>>>
>>>> Manikanta Pubbisetty (3):
>>>>    ath11k: Fix double free issue during SRNG deinit
>>>>    ath11k: Move hardware initialization logic to start()
>>>>    ath11k: Enable low power mode when WLAN is not active
>>>> ---
>>>> V3:
>>>>   - Removed patch "ath11k: Fix failed to parse regulatory event print" as it is not needed anymore
>>>>   - Fixed a potential deadlock scenario reported by lockdep around ab->core_lock with V2 changes
>>>>   - Fixed other minor issues that were found during code review
>>>>   - Spelling corrections in the commit messages
>>>
>>> I still see a crash, immediately after the first rmmod:
>>>
>>> Nov 22 11:05:47 nuc2  [  139.378719] rmmod ath11k_pci
>>> Nov 22 11:05:48 nuc2 [ 139.892395] general protection fault, probably
>>> for non-canonical address 0xdffffc000000003e: 0000 [#1] PREEMPT SMP
>>> DEBUG_PAGEALLOC KASAN
>>> Nov 22 11:05:48 nuc2 [ 139.892453] KASAN: null-ptr-deref in range
>>> [0x00000000000001f0-0x00000000000001f7]
>>>
>>> Really odd that you don't see it. Unfortunately not able to debug this
>>> further right now.
>>>
>>> This is with:
>>>
>>> wcn6855 hw2.0 WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.9
>>
>> A bit more information how I see the crash. So first I have all modules
>> loaded:
>>
>> $ lsmod
>> Module                  Size  Used by
>> ath11k_pci             57344  0
>> ath11k               2015232  1 ath11k_pci
>> mac80211             3284992  1 ath11k
>> libarc4                16384  1 mac80211
>> cfg80211             2494464  2 ath11k,mac80211
>> qmi_helpers            57344  1 ath11k
>> qrtr_mhi               20480  0
>> mhi                   217088  2 ath11k_pci,qrtr_mhi
>> qrtr                   98304  5 qrtr_mhi
>> nvme                  122880  3
>> nvme_core             299008  5 nvme
>> $
>>
>> Then I just remove ath11k_pci module and boom:
>>
>> $ sudo rmmod ath11k_pci
>>
>> [ 153.658409] general protection fault, probably for non-canonical
>> address 0xdffffc000000003e: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
>> KASAN
>>
>> This happens every time, there doesn't seem to be any randomness on the
>> behaviour.
>>
>
> Thanks for the help Kalle, this is exactly what I was doing in my
> tests. Unfortunately, I'm not able to reproduce the problem. I have
> also tried with the exact firmware that you have pointed out. Let me
> see if I'm missing anything.

I tested this more and patch 3 seems to be the one causing the crash. I
didn't see this when patch 1-2 were applied.

The crash happens in ath11k_dp_process_rxdma_err() in this line:

	srng = &ab->hal.srng_list[err_ring->ring_id];

ab looks sane to me (0xffff88814c960000) but err_ring is set to 0x200.
Does this help?

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

  reply	other threads:[~2022-12-08  7:54 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-21 11:03 [PATCH v3 0/3] Enable low power mode when WLAN is not active Manikanta Pubbisetty
2022-11-21 11:03 ` Manikanta Pubbisetty
2022-11-21 11:03 ` [PATCH v3 1/3] ath11k: Fix double free issue during SRNG deinit Manikanta Pubbisetty
2022-11-21 11:03   ` Manikanta Pubbisetty
2022-11-21 11:03 ` [PATCH v3 2/3] ath11k: Move hardware initialization logic to start() Manikanta Pubbisetty
2022-11-21 11:03   ` Manikanta Pubbisetty
2022-11-21 11:03 ` [PATCH v3 3/3] ath11k: Enable low power mode when WLAN is not active Manikanta Pubbisetty
2022-11-21 11:03   ` Manikanta Pubbisetty
2022-11-21 16:17 ` [PATCH v3 0/3] " Kalle Valo
2022-11-21 16:17   ` Kalle Valo
2022-11-22  9:11 ` Kalle Valo
2022-11-22  9:11   ` Kalle Valo
2022-11-23 16:05   ` Kalle Valo
2022-11-23 16:05     ` Kalle Valo
2022-11-25  4:29     ` Manikanta Pubbisetty
2022-11-25  4:29       ` Manikanta Pubbisetty
2022-12-08  7:54       ` Kalle Valo [this message]
2022-12-08  7:54         ` Kalle Valo
2022-12-08 11:20         ` Manikanta Pubbisetty
2022-12-08 11:20           ` Manikanta Pubbisetty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y1ri1gay.fsf@kernel.org \
    --to=kvalo@kernel.org \
    --cc=ath11k@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=quic_mpubbise@quicinc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.