Received-SPF: pass (google.com: domain of linux-wireless+bounces-300-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Fri, 1 Dec 2023 16:26:28 +0100
From: Luca Ceresoli <luca.ceresoli@bootlin.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: linux-wireless@vger.kernel.org, imx@lists.linux.dev
Subject: Re: Linux v6.6 sporadic reboot failures with ath9k on i.MX6Q
Message-ID: <20231201162628.715983d6@booty>
In-Reply-To: <016b48b0-2021-434f-88c7-deb1bf08d14a@gmail.com>
References: <20231129102240.183f94ba@booty>
	<016b48b0-2021-434f-88c7-deb1bf08d14a@gmail.com>
Organization: Bootlin
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hello Florian,

On Wed, 29 Nov 2023 21:10:44 -0800
Florian Fainelli <f.fainelli@gmail.com> wrote:

> Do you have a reboot log with "initcall_debug debug" set on the kernel 
> command line and if so, does it always point to the PCI bus shutting 
> down the device drivers, pcie ports and ultimately the root complex?
> 
> We have seen something similar before with ath10k_pci and our 
> pcie-brcmstb driver which eventually was a result of having made 
> incorrect assumptions while implementing the platform_driver::shutdown 
> routine. There was a hard hang in ath10k_remove(), I do not recall the 
> details, but we were definitively doing something improper there.
> 
> imx6_pcie_shutdown() seems to much simpler, but my first guess would be 
> there.

I had attempted using initcall_debug but the hang was happening on a
different line across tests, so it did not reliably point to a specific
place. Perhaps the serial port just stopped working before being able
to flush the last few lines.

I will have the shutdown code, even though it did not seems to the
problematic.

Thank you for your hints.

Best regards,
Luca

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com