From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6B0A2C4167B for ; Thu, 7 Dec 2023 14:49:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=RDv4F8BUY2l7abE95XKBHwBUCJvRRPGSkBrIMWSU9ys=; b=PGzcbQO+VLZem23mFaw2l8GDVq i2G4MO4fPrvHHnxVF0HSqc0MJMC9D9WICQM97jAZfLHIsvDUTSjMGxE3CxZaSnJfIVVhvVbCosaMD FGUJ5pUBRKdDuTOS8Pm/+YjVi2jOhFL2MzjJoYX9ykXFTRigQ4aGs2+xbPtFO10eyJTFuw+Vrtqpu tQLlVi0aXOOKMXFBEt7eUqJ/3oNDJ5k0rsAUYRcaShfhVUo7R0K7KmUlH/q3P4SBuvOelmF6CwfTX Xb1H1RDHIG+jQzli0j51dY2AOUIS58qspo0N4pkCWu9es5g2pgaOhyNBpDV/mibvV5VeM+9op4o0h 3dkxF9zA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rBFgx-00D4IB-07; Thu, 07 Dec 2023 14:49:31 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rBFgu-00D4Hq-1m for ath10k@lists.infradead.org; Thu, 07 Dec 2023 14:49:30 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id 167F1B81C1D; Thu, 7 Dec 2023 14:49:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E1133C433C7; Thu, 7 Dec 2023 14:49:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701960566; bh=IcBWMYQlbFYpDxnAIk+Jk20qDDu9aXKuMpFk3AIunOw=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=W2JCN7X/eXCeAegQm6DdAqck67UHemwbx5CjDZq96bBLybUHuSknz5K6rHOKkYdLl zc6lcsgLDJtmhUKLl2pEQrDSJwpGXqe5rEz5FZB2h134EZ2Y06UvklhrtN4XmkfAxk G4kUAd61MDzBjK92XPhdIOOd7wVKjPmySRMo0S09IQDfXxvw4IeTByl68Er78s2kOg T9PvQflC1CwgqIzMgk8M35zZDrRRJcOTLo8tJGNmSCGlonDYaenpnm1ct79ZAoESMx MQhv2TRfZWZncrkdA7TZpQxa9vmoMk3JTd0bppGiJenwgnbxQu9ykRMp5/nC9t8fdO NUqmtRY5AOZzg== From: Kalle Valo To: Yongqin Liu Cc: Douglas Anderson , ath10k@lists.infradead.org, Abhishek Kumar , Youghandhar Chintala , linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org, Manivannan Sadhasivam , Sumit Semwal , John Stultz , Viktor Martensson , Amit Pundir Subject: Re: [PATCH] ath10k: Don't touch the CE interrupt registers after power up References: <20230630151842.1.If764ede23c4e09a43a842771c2ddf99608f25f8e@changeid> Date: Thu, 07 Dec 2023 16:49:21 +0200 In-Reply-To: (Yongqin Liu's message of "Thu, 7 Dec 2023 22:29:03 +0800") Message-ID: <87wmtqnk3y.fsf@kernel.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231207_064928_856764_60E6A8C6 X-CRM114-Status: GOOD ( 22.27 ) X-BeenThere: ath10k@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "ath10k" Errors-To: ath10k-bounces+ath10k=archiver.kernel.org@lists.infradead.org Yongqin Liu writes: > On Sat, 1 Jul 2023 at 06:19, Douglas Anderson wrote: >> >> As talked about in commit d66d24ac300c ("ath10k: Keep track of which >> interrupts fired, don't poll them"), if we access the copy engine >> register at a bad time then ath10k can go boom. However, it's not >> necessarily easy to know when it's safe to access them. >> >> The ChromeOS test labs saw a crash that looked like this at >> shutdown/reboot time (on a chromeos-5.15 kernel, but likely the >> problem could also reproduce upstream): >> >> Internal error: synchronous external abort: 96000010 [#1] PREEMPT SMP >> ... >> CPU: 4 PID: 6168 Comm: reboot Not tainted >> 5.15.111-lockdep-19350-g1d624fe6758f #1 >> 010b9b233ab055c27c6dc88efb0be2f4e9e86f51 >> Hardware name: Google Kingoftown (DT) >> ... >> pc : ath10k_snoc_read32+0x50/0x74 [ath10k_snoc] >> lr : ath10k_snoc_read32+0x24/0x74 [ath10k_snoc] >> ... >> Call trace: >> ath10k_snoc_read32+0x50/0x74 [ath10k_snoc ...] >> ath10k_ce_disable_interrupt+0x190/0x65c [ath10k_core ...] >> ath10k_ce_disable_interrupts+0x8c/0x120 [ath10k_core ...] >> ath10k_snoc_hif_stop+0x78/0x660 [ath10k_snoc ...] >> ath10k_core_stop+0x13c/0x1ec [ath10k_core ...] >> ath10k_halt+0x398/0x5b0 [ath10k_core ...] >> ath10k_stop+0xfc/0x1a8 [ath10k_core ...] >> drv_stop+0x148/0x6b4 [mac80211 ...] >> ieee80211_stop_device+0x70/0x80 [mac80211 ...] >> ieee80211_do_stop+0x10d8/0x15b0 [mac80211 ...] >> ieee80211_stop+0x144/0x1a0 [mac80211 ...] >> __dev_close_many+0x1e8/0x2c0 >> dev_close_many+0x198/0x33c >> dev_close+0x140/0x210 >> cfg80211_shutdown_all_interfaces+0xc8/0x1e0 [cfg80211 ...] >> ieee80211_remove_interfaces+0x118/0x5c4 [mac80211 ...] >> ieee80211_unregister_hw+0x64/0x1f4 [mac80211 ...] >> ath10k_mac_unregister+0x4c/0xf0 [ath10k_core ...] >> ath10k_core_unregister+0x80/0xb0 [ath10k_core ...] >> ath10k_snoc_free_resources+0xb8/0x1ec [ath10k_snoc ...] >> ath10k_snoc_shutdown+0x98/0xd0 [ath10k_snoc ...] >> platform_shutdown+0x7c/0xa0 >> device_shutdown+0x3e0/0x58c >> kernel_restart_prepare+0x68/0xa0 >> kernel_restart+0x28/0x7c >> >> Though there's no known way to reproduce the problem, it makes sense >> that it would be the same issue where we're trying to access copy >> engine registers when it's not allowed. >> >> Let's fix this by changing how we "disable" the interrupts. Instead of >> tweaking the copy engine registers we'll just use disable_irq() and >> enable_irq(). Then we'll configure the interrupts once at power up >> time. >> >> Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.2.2.c10-00754-QCAHLSWMTPL-1 >> >> Signed-off-by: Douglas Anderson >> --- > > Recently during our Android build test on the Dragonboard 845c board, > with the Android Common Kernel android11-5.4-lts and android12-5.4-lts branches, > > we found there are some ufshcd related changes printed, > and the serial console gets stuck, no response for input, > and the Android boot is stuck at the animation window. > > The problem is reported here > https://issuetracker.google.com/issues/314366682 > You could check there for more log details. > > And with some bisection, I found it's related to this commit, > when I revert this commit, the problem is gone. > > So replied here, not sure if you have any idea about it, > or any suggestions on what we should do next to resolve the problem? FWIW we don't support Android kernels, only kernel.org releases. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches