From: Brian Masney <bmasney@redhat.com>
To: Lucas Tanure <tanure@linux.com>
Cc: Neil Armstrong <neil.armstrong@linaro.org>,
Jerome Brunet <jbrunet@baylibre.com>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
Kevin Hilman <khilman@baylibre.com>,
Jian Hu <jian.hu@amlogic.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
linux-amlogic@lists.infradead.org, linux-clk@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] clk: meson: t7: Intermittent boot instability and memory corruption on VIM4
Date: Mon, 24 Aug 2026 11:29:35 -0400 [thread overview]
Message-ID: <aoxjX3HabY0brgXk@redhat.com> (raw)
In-Reply-To: <3930906f-783b-4d72-9260-ba25cc8081cb@linux.com>
Hi Lucas,
On Sun, Aug 23, 2026 at 04:40:42PM +0100, Lucas Tanure wrote:
> While testing mainline Linux on the Khadas VIM4 (Amlogic A311D2 / T7), I am
> hitting intermittent system instability, storage loss, and memory corruption
> during boot, unless I append clk_ignore_unused to the kernel command line.
>
> Because the failure is intermittent, I am running 100-reboot test campaigns
> to bisect the remaining clocks and isolate which clocks are critical and
> cannot be safely disabled.
>
> As testing takes significant time over serial console, I wanted to check if
> Amlogic or the maintainers could shed light on this:
>
> Are there specific T7 clocks or hardware domains that must remain
> critical/protected even without an explicit in-kernel consumer?
>
> Current clocks being disabled that don't kill the board on a test run:
>
> [ 0.380313] clk: Disabling unused clocks
> [ 0.380413] clk: Disabled unused clock: rtc_dualdiv
> [ 0.380718] clk: Disabled unused clock: rtc_duandiv_in
> [ 0.381377] clk: Unprepared unused clock: a73_div16
> [ 0.381972] clk: Unprepared unused clock: cpu_div16
> [ 0.382605] clk: Unprepared unused clock: f50m
> [ 0.383174] clk: Unprepared unused clock: fixed_pll_dco
> [ 0.383786] clk: Unprepared unused clock: hdmi_pll_osc
> [ 0.384416] clk: Unprepared unused clock: sys1_pll_osc
> [ 0.385056] clk: Unprepared unused clock: earc_osc
> [ 0.385652] clk: Unprepared unused clock: pcie_refclk_osc
> [ 0.386323] clk: Unprepared unused clock: eth_pll_osc
> [ 0.386961] clk: Unprepared unused clock: pcie_osc
> [ 0.387548] clk: Unprepared unused clock: mclk_pll_osc
> [ 0.388187] clk: Unprepared unused clock: usb_pll1_osc
> [ 0.388826] clk: Unprepared unused clock: usb_pll0_osc
> [ 0.389465] clk: Unprepared unused clock: tcon_pll_osc
> [ 0.390105] clk: Unprepared unused clock: top_pll_osc
> [ 0.390738] clk: Unprepared unused clock: aud_pll_osc
> [ 0.391361] clk: Unprepared unused clock: ddr_pll_osc
>
> I am not forcing any clock to be disabled; I am forcing all clocks to stay
> on and letting them be disabled if unused one by one.
>
> Any guidance or hints on required platform clocks would be greatly
> appreciated.
I have an outstanding series that disables unused clocks via the
sync_state callback:
https://lore.kernel.org/linux-clk/20260626-clk-sync-state-v1-0-4156d8196dc8@redhat.com/
Be sure to not have clk_ignore_unused in your kernel command line.
I suggest comparing the list of which clocks are disabled with that
series against your list of clocks above.
Brian
WARNING: multiple messages have this Message-ID (diff)
From: Brian Masney <bmasney@redhat.com>
To: Lucas Tanure <tanure@linux.com>
Cc: Neil Armstrong <neil.armstrong@linaro.org>,
Jerome Brunet <jbrunet@baylibre.com>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
Kevin Hilman <khilman@baylibre.com>,
Jian Hu <jian.hu@amlogic.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
linux-amlogic@lists.infradead.org, linux-clk@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] clk: meson: t7: Intermittent boot instability and memory corruption on VIM4
Date: Mon, 24 Aug 2026 11:29:35 -0400 [thread overview]
Message-ID: <aoxjX3HabY0brgXk@redhat.com> (raw)
In-Reply-To: <3930906f-783b-4d72-9260-ba25cc8081cb@linux.com>
Hi Lucas,
On Sun, Aug 23, 2026 at 04:40:42PM +0100, Lucas Tanure wrote:
> While testing mainline Linux on the Khadas VIM4 (Amlogic A311D2 / T7), I am
> hitting intermittent system instability, storage loss, and memory corruption
> during boot, unless I append clk_ignore_unused to the kernel command line.
>
> Because the failure is intermittent, I am running 100-reboot test campaigns
> to bisect the remaining clocks and isolate which clocks are critical and
> cannot be safely disabled.
>
> As testing takes significant time over serial console, I wanted to check if
> Amlogic or the maintainers could shed light on this:
>
> Are there specific T7 clocks or hardware domains that must remain
> critical/protected even without an explicit in-kernel consumer?
>
> Current clocks being disabled that don't kill the board on a test run:
>
> [ 0.380313] clk: Disabling unused clocks
> [ 0.380413] clk: Disabled unused clock: rtc_dualdiv
> [ 0.380718] clk: Disabled unused clock: rtc_duandiv_in
> [ 0.381377] clk: Unprepared unused clock: a73_div16
> [ 0.381972] clk: Unprepared unused clock: cpu_div16
> [ 0.382605] clk: Unprepared unused clock: f50m
> [ 0.383174] clk: Unprepared unused clock: fixed_pll_dco
> [ 0.383786] clk: Unprepared unused clock: hdmi_pll_osc
> [ 0.384416] clk: Unprepared unused clock: sys1_pll_osc
> [ 0.385056] clk: Unprepared unused clock: earc_osc
> [ 0.385652] clk: Unprepared unused clock: pcie_refclk_osc
> [ 0.386323] clk: Unprepared unused clock: eth_pll_osc
> [ 0.386961] clk: Unprepared unused clock: pcie_osc
> [ 0.387548] clk: Unprepared unused clock: mclk_pll_osc
> [ 0.388187] clk: Unprepared unused clock: usb_pll1_osc
> [ 0.388826] clk: Unprepared unused clock: usb_pll0_osc
> [ 0.389465] clk: Unprepared unused clock: tcon_pll_osc
> [ 0.390105] clk: Unprepared unused clock: top_pll_osc
> [ 0.390738] clk: Unprepared unused clock: aud_pll_osc
> [ 0.391361] clk: Unprepared unused clock: ddr_pll_osc
>
> I am not forcing any clock to be disabled; I am forcing all clocks to stay
> on and letting them be disabled if unused one by one.
>
> Any guidance or hints on required platform clocks would be greatly
> appreciated.
I have an outstanding series that disables unused clocks via the
sync_state callback:
https://lore.kernel.org/linux-clk/20260626-clk-sync-state-v1-0-4156d8196dc8@redhat.com/
Be sure to not have clk_ignore_unused in your kernel command line.
I suggest comparing the list of which clocks are disabled with that
series against your list of clocks above.
Brian
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
next prev parent reply other threads:[~2026-08-24 15:29 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-23 15:40 [RFC] clk: meson: t7: Intermittent boot instability and memory corruption on VIM4 Lucas Tanure
2026-08-23 15:40 ` Lucas Tanure
2026-08-24 15:29 ` Brian Masney [this message]
2026-08-24 15:29 ` Brian Masney
2026-08-26 9:55 ` Lucas Tanure
2026-08-26 9:55 ` Lucas Tanure
2026-08-26 16:42 ` Lucas Tanure
2026-08-26 16:42 ` Lucas Tanure
2026-08-26 17:17 ` Brian Masney
2026-08-26 17:17 ` Brian Masney
2026-08-26 20:04 ` Lucas Tanure
2026-08-26 20:04 ` Lucas Tanure
2026-08-27 3:04 ` Chuan Liu
2026-08-27 3:04 ` Chuan Liu
2026-08-26 9:02 ` Neil Armstrong
2026-08-26 9:02 ` Neil Armstrong
2026-08-26 9:57 ` Lucas Tanure
2026-08-26 9:57 ` Lucas Tanure
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=aoxjX3HabY0brgXk@redhat.com \
--to=bmasney@redhat.com \
--cc=jbrunet@baylibre.com \
--cc=jian.hu@amlogic.com \
--cc=khilman@baylibre.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.blumenstingl@googlemail.com \
--cc=mturquette@baylibre.com \
--cc=neil.armstrong@linaro.org \
--cc=sboyd@kernel.org \
--cc=tanure@linux.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 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.