[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdZp=4sP_1a=u6c7DGbPWA8WRee4J8Wpsw7Y57S2FT5GFw@mail.gmail.com>
Date: Wed, 29 Nov 2023 22:33:00 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Rafał Miłecki <zajec5@...il.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
Waiman Long <longman@...hat.com>,
Boqun Feng <boqun.feng@...il.com>,
Russell King <linux@...linux.org.uk>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>,
Florian Fainelli <f.fainelli@...il.com>,
linux-clk@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
openwrt-devel@...ts.openwrt.org,
bcm-kernel-feedback-list@...adcom.com
Subject: Re: ARM BCM53573 SoC hangs/lockups caused by locks/clock/random changes
On Wed, Nov 29, 2023 at 10:20 PM Rafał Miłecki <zajec5@...il.com> wrote:
> Here comes more interesting experiment though. Putting there:
>
> if (!(foo++ % 10000)) {
> pr_info("[%s] arm_pm_idle:%ps\n", __func__, arm_pm_idle);
> }
>
> doesn't seem to help.
>
>
> Putting following however seems to make kernel/device stable:
>
> if (!(foo++ % 100)) {
> pr_info("[%s] arm_pm_idle:%ps\n", __func__, arm_pm_idle);
> }
That's just too weird.
> I think I'm just going to assume those chipsets are simply hw broken.
If disabling CPU idle on these altogether stabilize them, then maybe that
is what we need to do?
Yours,
Linus Walleij
Powered by blists - more mailing lists