linux-kernel - Re: clk_imx8mp_audiomix_runtime_resume Kernel panic regression on v6.12

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20241112092054.GA18139@francesco-nb>
Date: Tue, 12 Nov 2024 10:20:54 +0100
From: Francesco Dolcini <francesco@...cini.it>
To: Shengjiu Wang <shengjiu.wang@....com>, Frank Li <frank.li@....com>
Cc: Shengjiu Wang <shengjiu.wang@....com>, abelvesa@...nel.org,
	peng.fan@....com, mturquette@...libre.com, sboyd@...nel.org,
	shawnguo@...nel.org, s.hauer@...gutronix.de, kernel@...gutronix.de,
	festevam@...il.com, linux-imx@....com, shengjiu.wang@...il.com,
	linux-clk@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, regressions@...ts.linux.dev,
	Adam Ford <aford173@...il.com>,
	Alexander Stein <alexander.stein@...tq-group.com>,
	Mark Brown <broonie@...nel.org>, ulf.hansson@...aro.org
Subject: Re: clk_imx8mp_audiomix_runtime_resume Kernel panic regression on
 v6.12

On Tue, Nov 12, 2024 at 08:59:58AM +0100, Francesco Dolcini wrote:
> On Mon, Oct 07, 2024 at 03:25:55PM +0200, Francesco Dolcini wrote:
> > it seems that an old regression is back on v6.12, reproduced on -rc2
> > (not sure about rc1).
> > 
> > The original report is from https://lore.kernel.org/all/20240424164725.GA18760@francesco-nb/
> > and it was fixed with https://lore.kernel.org/all/1715396125-3724-1-git-send-email-shengjiu.wang@nxp.com/.
> > 
> > Is it now back?
> 
> I was able to reproduce this issue once more, this time with 6.11.7.
> As I wrote in another email the issue is not systematic as it used to
> be.
> 
> Any idea?

Frank, Shengjiu, could it be that the udelay(5) in imx_pgc_power_up() is
too short and therefore we have such non-systematic failures?

Francesco