[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdVTQdj5OUHX7em3Zhiy1n935DVJBb0LKk1+_azmzQNxxg@mail.gmail.com>
Date: Mon, 4 Sep 2023 10:58:03 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.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
Hi Rafał,
On Mon, Sep 4, 2023 at 10:35 AM Rafał Miłecki <zajec5@...il.com> wrote:
> 2. Clock (arm,armv7-timer)
>
> While comparing main clock in Broadcom's SDK with upstream one I noticed
> a tiny difference: mask value. I don't know it it makes any sense but
> switching from CLOCKSOURCE_MASK(56) to CLOCKSOURCE_MASK(64) in
> arm_arch_timer.c (to match SDK) increases average uptime (time before a
> hang/lockup happens) from 4 minutes to 36 minutes.
That code path is used only for type != ARCH_TIMER_TYPE_CP15,
but your kernel log
arch_timer: cp15 timer(s) running at 0.03MHz (virt).
suggest that type == ARCH_TIMER_TYPE_CP15?!?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Powered by blists - more mailing lists