From: "Rafał Miłecki" <zajec5@gmail.com>
To: Linus Walleij <linus.walleij@linaro.org>
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 22:20:38 +0100 [thread overview]
Message-ID: <ec17c6c8-e697-4a5a-a705-bff24daae7b2@gmail.com> (raw)
In-Reply-To: <CACRpkdahWm9aP+UasDx=s3th+vyjAfuWrKB5HS9BKEbz90ZmKw@mail.gmail.com>
Hi,
it's a late reply but I didn't find enough determination earlier.
On 8.09.2023 10:10, Linus Walleij wrote:
> On Mon, Sep 4, 2023 at 10:34 AM Rafał Miłecki <zajec5@gmail.com> wrote:
>
>> I'm clueless at this point.
>> Maybe someone can come up with an idea of actual issue & ideally a
>> solution.
>
> Damn this is frustrating.
>
>> 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.
>
> This could be related to how often the system goes to idle.
>
>> + if (cpu_idle_force_poll == 1234)
>> + arch_cpu_idle();
>> + if (cpu_idle_force_poll == 5678)
>> + arch_cpu_idle();
>> + if (cpu_idle_force_poll == 1234)
>> + arch_cpu_idle();
>> + if (cpu_idle_force_poll == 5678)
>> + arch_cpu_idle();
>> + if (cpu_idle_force_poll == 1234)
>> + arch_cpu_idle();
>> + if (cpu_idle_force_poll == 5678)
>> + arch_cpu_idle();
>> + if (cpu_idle_force_poll == 1234)
>> + arch_cpu_idle();
>
> Idle again.
>
> I would have tried to see what arch_cpu_idle() is doing.
>
> arm_pm_idle() or cpu_do_idle()?
In my case arm_pm_idle is NULL.
> What happens if you just put return in arch_cpu_idle()
> so it does nothing?
Doesn't help. I also tried putting:
udelay(10);
and
udelay(1000);
at the arch_cpu_idle() beginning. None helped.
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);
}
I think I'm just going to assume those chipsets are simply hw broken.
WARNING: multiple messages have this Message-ID (diff)
From: "Rafał Miłecki" <zajec5@gmail.com>
To: Linus Walleij <linus.walleij@linaro.org>
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 22:20:38 +0100 [thread overview]
Message-ID: <ec17c6c8-e697-4a5a-a705-bff24daae7b2@gmail.com> (raw)
In-Reply-To: <CACRpkdahWm9aP+UasDx=s3th+vyjAfuWrKB5HS9BKEbz90ZmKw@mail.gmail.com>
Hi,
it's a late reply but I didn't find enough determination earlier.
On 8.09.2023 10:10, Linus Walleij wrote:
> On Mon, Sep 4, 2023 at 10:34 AM Rafał Miłecki <zajec5@gmail.com> wrote:
>
>> I'm clueless at this point.
>> Maybe someone can come up with an idea of actual issue & ideally a
>> solution.
>
> Damn this is frustrating.
>
>> 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.
>
> This could be related to how often the system goes to idle.
>
>> + if (cpu_idle_force_poll == 1234)
>> + arch_cpu_idle();
>> + if (cpu_idle_force_poll == 5678)
>> + arch_cpu_idle();
>> + if (cpu_idle_force_poll == 1234)
>> + arch_cpu_idle();
>> + if (cpu_idle_force_poll == 5678)
>> + arch_cpu_idle();
>> + if (cpu_idle_force_poll == 1234)
>> + arch_cpu_idle();
>> + if (cpu_idle_force_poll == 5678)
>> + arch_cpu_idle();
>> + if (cpu_idle_force_poll == 1234)
>> + arch_cpu_idle();
>
> Idle again.
>
> I would have tried to see what arch_cpu_idle() is doing.
>
> arm_pm_idle() or cpu_do_idle()?
In my case arm_pm_idle is NULL.
> What happens if you just put return in arch_cpu_idle()
> so it does nothing?
Doesn't help. I also tried putting:
udelay(10);
and
udelay(1000);
at the arch_cpu_idle() beginning. None helped.
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);
}
I think I'm just going to assume those chipsets are simply hw broken.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-11-29 21:20 UTC|newest]
Thread overview: 22+ 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:33 ` Rafał Miłecki
2023-09-04 8:58 ` Geert Uytterhoeven
2023-09-04 8:58 ` Geert Uytterhoeven
2023-09-04 15:25 ` Waiman Long
2023-09-04 15:25 ` Waiman Long
2023-09-04 15:40 ` Russell King (Oracle)
2023-09-04 15:40 ` Russell King (Oracle)
2023-09-04 20:16 ` Waiman Long
2023-09-04 20:16 ` Waiman Long
2023-09-05 20:07 ` Florian Fainelli
2023-09-05 20:07 ` Florian Fainelli
2023-09-06 2:17 ` Waiman Long
2023-09-06 2:17 ` Waiman Long
2023-09-08 8:10 ` Linus Walleij
2023-09-08 8:10 ` Linus Walleij
2023-11-29 21:20 ` Rafał Miłecki [this message]
2023-11-29 21:20 ` Rafał Miłecki
2023-11-29 21:33 ` Linus Walleij
2023-11-29 21:33 ` Linus Walleij
2023-11-29 21:42 ` Florian Fainelli
2023-11-29 21:42 ` Florian Fainelli
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=ec17c6c8-e697-4a5a-a705-bff24daae7b2@gmail.com \
--to=zajec5@gmail.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 \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.