[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <92190d04-9b43-47ad-9dd0-4b85bb60f8ef@broadcom.com>
Date: Wed, 29 Nov 2023 13:42:38 -0800
From: Florian Fainelli <florian.fainelli@...adcom.com>
To: Linus Walleij <linus.walleij@...aro.org>, 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 11/29/23 13:33, Linus Walleij wrote:
> 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.
It does seem to indicate that idling for too long wrecks havoc, but it
is indeed not making much sense. Not having proper documentation for
this SoC, it is hard to figure out what impact does stopping the ARM CPU
clock has on the rest of the memory subsystem, especially outside of the
CPU. I do not believe that this SoC has any form of PLL clock gating or
pulse skipping.
>
>> 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?
Yes, please try booting with "nohlt" set on the kernel command line and
see how that fares.
Also useful would be to dump the L2 CTLR and L2 ECTLR, this is a
complete shot in the dark, though was initially wondering if there could
be some retention issues, and would have recommended disabling the L2
retention policy completely just for testing.
MRC p15, 1, <Rt>, c9, c0, 2;
of particular interest here would be bit at position 0, try to see if
changing it to 1 (3 cycles) or 0 (2 cycles) changes anything.
MRC p15, 1, <Rt>, c9, c0, 3;
the lower bits are reserved, so I would not necessarily expect them to
be mapping to configurable latencies, but if you see non-zero values in
bits [28:0], try changing them to 0 and see if that changes anything.
Thanks for your persistence!
--
Florian
Download attachment "smime.p7s" of type "application/pkcs7-signature" (4221 bytes)
Powered by blists - more mailing lists