From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-ed1-x542.google.com ([2a00:1450:4864:20::542]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1koErN-000328-OP for ath11k@lists.infradead.org; Sun, 13 Dec 2020 00:03:35 +0000 Received: by mail-ed1-x542.google.com with SMTP id cm17so13363369edb.4 for ; Sat, 12 Dec 2020 16:03:33 -0800 (PST) MIME-Version: 1.0 References: <87r1nz9emq.fsf@codeaurora.org> <87mtyn9dx0.fsf@codeaurora.org> <874kkr4mba.fsf@codeaurora.org> In-Reply-To: From: wi nk Date: Sun, 13 Dec 2020 01:03:21 +0100 Message-ID: Subject: Re: ath11k: QCA6390 on Dell XPS 13 and kernel crashes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "ath11k" Errors-To: ath11k-bounces+kvalo=adurom.com@lists.infradead.org To: Kalle Valo Cc: Stephen Liang , Carl Huang , "ath11k@lists.infradead.org" , Mitchell Nordine On Sun, Dec 13, 2020 at 12:29 AM wi nk wrote: > > On Sat, Dec 12, 2020 at 12:46 PM wi nk wrote: > > > > On Sat, Dec 12, 2020 at 6:37 AM Kalle Valo wrote: > > > > > > wi nk writes: > > > > > > >> > and the modification that disables m2 state: > > > >> > > > > >> > diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c > > > >> > index 3de7b1639ec6..20f670c8b129 100644 > > > >> > --- a/drivers/bus/mhi/core/pm.c > > > >> > +++ b/drivers/bus/mhi/core/pm.c > > > >> > @@ -55,12 +55,12 @@ static struct mhi_pm_transitions const > > > >> > dev_state_transitions[] = { > > > >> > }, > > > >> > { > > > >> > MHI_PM_M0, > > > >> > - MHI_PM_M0 | MHI_PM_M2 | MHI_PM_M3_ENTER | > > > >> > + MHI_PM_M0 | MHI_PM_M3_ENTER | > > > >> > MHI_PM_SYS_ERR_DETECT | MHI_PM_SHUTDOWN_PROCESS | > > > >> > MHI_PM_LD_ERR_FATAL_DETECT | MHI_PM_FW_DL_ERR > > > >> > }, > > > >> > { > > > >> > - MHI_PM_M2, > > > >> > + MHI_PM_M0, > > > >> > MHI_PM_M0 | MHI_PM_SYS_ERR_DETECT | MHI_PM_SHUTDOWN_PROCESS | > > > >> > MHI_PM_LD_ERR_FATAL_DETECT > > > >> > }, > > > >> > > > >> Adding one more data point. The driver will not crash on > > > >> initialization this way, but also with the M2 state transition > > > >> disabled the system survives suspend and wake and the adapter > > > >> successfully reassociates consistently. As expected with my patch, > > > >> the MHI driver shows everything stays in the M1 state instead of > > > >> attempting to transition to M2 ever. It also doesn't return back to > > > >> M0 if I disconnect the power / replug it. I'm not sure what things > > > >> are affected by me hacking this state machine, but avoiding that M2 > > > >> transition has removed any obvious issues from my system. > > > > > > > > While waiting for someone else to confirm, I can report that I've > > > > still not seen any instability since this patch. The laptop has been > > > > stable through reboots, power cycling, suspension, etc. > > > > > > Very interesting! Are you saying that with this patch the wireless > > > connection using QCA6390 works fine on your Dell XPS 9310, you can > > > connect to an AP and transfer data normally? > > > > > > > Precisely. The machine is now over 24h of uptime, I can reboot/sleep > > without any issues, and throughput seems to saturate my wifi link > > (5-600mpbs). > > > > > > > I would like to submit your patch to patchwork.kernel.org as RFC patch > > > so that it's easier for everyone to download. But before I can do that I > > > need your Signed-off-by, can you read Developer's Certificate of Origin: > > > > > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin > > > > > > And if you agree with the DCO please send your s-o-b by replying to this > > > email. But you can also submit the RFC patch yourself, instructions > > > here: > > > > > > https://wireless.wiki.kernel.org/en/users/drivers/ath11k/submittingpatches > > > > > > > Signed-off-by: Lee Smith > > > > I'll get an email out later this afternoon, if you get there first, > > please feel free :). > > > > > > I'd be happy to continue to try to understand why this is this case. > > > > It sounds like Stephen isn't seeing these issues on 5.10 rc6 with the > > > > single msi patch+reverting that one commit. I can try to give that a > > > > shot if it'd produce something useful. > > > > > > Yes, being able to give datapoints what affects this bug is very helpful > > > to track down it. > > > > > > > Ok, I'll try to rebuild to that configuration later today and report back. > > > > > > Kalle - a couple quick questions, in the driver comments the M2 state > > > > is loosely documented as a low power mode. Why would it transition to > > > > that while on charger/plugging in, but stay in M0 while on battery > > > > (you can see this behavior in the videos I linked previously)? > > > > Naively I would've expected the opposite behavior. > > > > > > I would have expected the same as well, it does sound strange or we are > > > misunderstanding something. I'll try to find out why it's so. But if you > > > learn more, please do let me know. > > > > > > > Will do. > > > > > > Also, is there any way to prevent that transition other than my brute > > > > force? It seems on battery the 'nominal' state for it is M0, I'm not > > > > sure what the effect of it being left in this M1 state really is even > > > > though there's nothing observable. Lastly, any thoughts as to why it > > > > seems that transition causes the EE state to become invalid? > > > > > > TBH I'm not very familiar with MHI, you seem to already know it much > > > more better than I do :) I'll include more folks to the thread later, > > > hopefully they can help. > > > > > > > Thanks! > > > > > > > -- > > > https://patchwork.kernel.org/project/linux-wireless/list/ > > > > > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches > > Ok I tried to boot 5.10-rc6 with > 59c6d022df8efb450f82d33dd6a6812935bd022f (single msi) and reverted > 7fef431be9c9. With this kernel, I can't get the wifi adapter to come > up, but no freezing. I receive this consistently: > > [ 23.959920] mhi 0000:55:00.0: Requested to power ON > [ 23.960058] mhi 0000:55:00.0: Power on setup success > [ 24.362295] ath11k_pci 0000:55:00.0: Respond mem req failed, result: 1, err: > 0 > [ 24.362303] ath11k_pci 0000:55:00.0: qmi failed to respond fw mem req:-22 > [ 24.374433] ath11k_pci 0000:55:00.0: chip_id 0x0 chip_family 0xb board_id 0xf > f soc_id 0xffffffff > [ 24.374438] ath11k_pci 0000:55:00.0: fw_version 0x101c06cc fw_build_timestamp > 2020-06-24 19:50 fw_build_id > [ 25.450139] ath11k_pci 0000:55:00.0: failed to receive control response compl > etion, polling.. > [ 26.474154] ath11k_pci 0000:55:00.0: Service connect timeout > [ 26.474163] ath11k_pci 0000:55:00.0: failed to connect to HTT: -110 > [ 26.477247] ath11k_pci 0000:55:00.0: failed to start core: -110 > > With the latest bringup and my patch to disable M2, I'm still booting > and operating reliably. I took my bringup branch and merged 5.10-rc6 into it. It merges fine, and seems to be stable as well. -- ath11k mailing list ath11k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath11k