public inbox for linux-clk@vger.kernel.org
 help / color / mirror / Atom feed
From: Florian Fainelli <florian.fainelli@broadcom.com>
To: "Linus Walleij" <linus.walleij@linaro.org>,
	"Rafał Miłecki" <zajec5@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
	Waiman Long <longman@redhat.com>,
	Boqun Feng <boqun.feng@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Florian Fainelli <f.fainelli@gmail.com>,
	linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	openwrt-devel@lists.openwrt.org,
	bcm-kernel-feedback-list@broadcom.com
Subject: Re: ARM BCM53573 SoC hangs/lockups caused by locks/clock/random changes
Date: Wed, 29 Nov 2023 13:42:38 -0800	[thread overview]
Message-ID: <92190d04-9b43-47ad-9dd0-4b85bb60f8ef@broadcom.com> (raw)
In-Reply-To: <CACRpkdZp=4sP_1a=u6c7DGbPWA8WRee4J8Wpsw7Y57S2FT5GFw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1888 bytes --]

On 11/29/23 13:33, Linus Walleij wrote:
> On Wed, Nov 29, 2023 at 10:20 PM Rafał Miłecki <zajec5@gmail.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


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4221 bytes --]

      reply	other threads:[~2023-11-29 21:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-04  8:33 ARM BCM53573 SoC hangs/lockups caused by locks/clock/random changes Rafał Miłecki
2023-09-04  8:58 ` Geert Uytterhoeven
2023-09-04 15:25 ` Waiman Long
2023-09-04 15:40   ` Russell King (Oracle)
2023-09-04 20:16     ` Waiman Long
2023-09-05 20:07     ` Florian Fainelli
2023-09-06  2:17       ` Waiman Long
2023-09-08  8:10 ` Linus Walleij
2023-11-29 21:20   ` Rafał Miłecki
2023-11-29 21:33     ` Linus Walleij
2023-11-29 21:42       ` Florian Fainelli [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=92190d04-9b43-47ad-9dd0-4b85bb60f8ef@broadcom.com \
    --to=florian.fainelli@broadcom.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=boqun.feng@gmail.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=f.fainelli@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=longman@redhat.com \
    --cc=mingo@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=openwrt-devel@lists.openwrt.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    --cc=zajec5@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox