2143954_ja-JP

是

i.MX8MMカーネルがcpuidleでクラッシュする

こんにちは、

しばらく実行するとクラッシュするカスタム i.MX8MM ボードがあります。この問題は、Linux カーネルバージョン 6.1.55 (Yocto 4.2)とLinux カーネルバージョン 5.15.71 (Yocto 4.0)の両方で発生します。システムのデフォルトの CPU ガバナーはondemandです。CPU ガバナーをパフォーマンスに変更してテストしたところ、システムがクラッシュしなくなりました。

これがハードウェアの問題なのかカーネルの問題なのかを判断する方法について何か提案はありますか?そしてこの問題をどう解決すればいいのでしょうか?

関連するログは次のとおりです。

[32832.280148] audit: type=1327 audit(1751365801.520:22): proctitle=2F7573722F7362696E2F63726F6E64002D6E
[36432.304306] audit: type=1006 audit(1751369401.584:23): pid=3094 uid=0 subj=kernel old-auid=4294967295 auid=0 tty=(none) old-ses=4294967295 ses=15 res=1
[36432.317968] audit: type=1300 audit(1751369401.584:23): arch=c00000b7 syscall=64 success=yes exit=1 a0=3 a1=ffffd19f6b10 a2=1 a3=ffffa11e9020 items=0 ppid=265 pid=3094 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=15 comm="crond" exe="/usr/sbin/crond" subj=kernel key=(null)
[36432.344959] audit: type=1327 audit(1751369401.584:23): proctitle=2F7573722F7362696E2F63726F6E64002D6E
[37877.552323] rcu: INFO: rcu_preempt self-detected stall on CPU
[37877.558090] rcu:     2-...!: (1 ticks this GP) idle=d95/0/0x3 softirq=199976/199976 fqs=0
[37877.566100]  (t=5958 jiffies g=1820793 q=55)
[37877.570369] rcu: rcu_preempt kthread timer wakeup didn't happen for 5957 jiffies! g1820793 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
[37877.581933] rcu:     Possible timer handling issue on cpu=0 timer-softirq=157944
[37877.589067] rcu: rcu_preempt kthread starved for 5958 jiffies! g1820793 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0
[37877.599676] rcu:     Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
[37877.608805] rcu: RCU grace-period kthread stack dump:
[37877.613854] task:rcu_preempt     state:I stack:    0 pid:   13 ppid:     2 flags:0x00000008
[37877.622211] Call trace:
[37877.624655]  __switch_to+0x104/0x15c
[37877.628241]  __schedule+0x2b8/0x710
[37877.631733]  schedule+0x88/0x100
[37877.634962]  schedule_timeout+0x80/0xf0
[37877.638801]  rcu_gp_fqs_loop+0x118/0x2e0
[37877.642726]  rcu_gp_kthread+0x104/0x11c
[37877.646564]  kthread+0x150/0x160
[37877.649795]  ret_from_fork+0x10/0x20
[37877.653373] rcu: Stack dump where RCU GP kthread last ran:
[37877.658855] Task dump for CPU 0:
[37877.662081] task:swapper/0       state:R  running task     stack:    0 pid:    0 ppid:     0 flags:0x00000008
[37877.671999] Call trace:
[37877.674443]  __switch_to+0x104/0x15c
[37877.678021]  cpuidle_enter_state+0x25c/0x2f0
[37877.682296]  cpuidle_enter+0x38/0x50
[37877.685873]  do_idle+0x210/0x2a0
[37877.689103]  cpu_startup_entry+0x24/0x80
[37877.693027]  rest_init+0xe4/0xf4
[37877.696256]  arch_call_rest_init+0x10/0x1c
[37877.700356]  start_kernel+0x610/0x650
[37877.704020]  __primary_switched+0xbc/0xc4
[37877.708037] Task dump for CPU 0:
[37877.711264] task:swapper/0       state:R  running task     stack:    0 pid:    0 ppid:     0 flags:0x00000008
[37877.721181] Call trace:
[37877.723625]  __switch_to+0x104/0x15c
[37877.727203]  cpuidle_enter_state+0x25c/0x2f0
[37877.731475]  cpuidle_enter+0x38/0x50
[37877.735052]  do_idle+0x210/0x2a0
[37877.738281]  cpu_startup_entry+0x24/0x80
[37877.742205]  rest_init+0xe4/0xf4
[37877.745433]  arch_call_rest_init+0x10/0x1c
[37877.749531]  start_kernel+0x610/0x650
[37877.753194]  __primary_switched+0xbc/0xc4
[37877.757206] Task dump for CPU 2:
[37877.760431] task:swapper/2       state:R  running task     stack:    0 pid:    0 ppid:     1 flags:0x00000008
[37877.770349] Call trace:
[37877.772792]  dump_backtrace+0x0/0x19c
[37877.776457]  show_stack+0x18/0x70
[37877.779775]  sched_show_task+0x154/0x180
[37877.783701]  dump_cpu_task+0x44/0x58
[37877.787280]  rcu_dump_cpu_stacks+0xe8/0x12c

i.MX 8M | i.MX 8M ミニ | i.MX 8M ナノ

Linux

Yocto Project

Re: i.MX8MM Kernel crashes on cpuidle

こんにちは、ジョアンシーさん

テストの結果、PMIC がこの問題の原因であることがわかりました。

再開まで今しばらくお待ちください。

Re: i.MX8MM Kernel crashes on cpuidle

1つのボードだけにこの問題が発生した場合、前に述べたように、他のボードは問題がないため、ABテストを実行して、この問題がチップに関連しているかどうかを確認CAN。

Re: i.MX8MM Kernel crashes on cpuidle

こんにちは、ジョアンシーさん

情報をいただきありがとうございます。

しかし、障害のあるデバイス 1 台だけのためにカーネル構成を変更する予定はありません。問題の分析にはディストリビューターの協力を仰ぐ予定です。

Re: i.MX8MM Kernel crashes on cpuidle

i.MX のパフォーマンスを最適化するには、以下の手順を試してください。CPU がアイドル状態になるのを防ぐため、defconfig ファイルで CONFIG_ARM_PSCI_CPUIDLE=n を設定します。CONFIG_ARM_PSCI_CPUIDLE は CONFIG_CPU_FREQ に依存します。CONFIG_CPU_FREQ=n を設定できない場合は、CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y を CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y に設定することをお勧めします。これは、ユーザー空間で「echo performance」コマンドを使用するのと同じだと思います。

Re: i.MX8MM Kernel crashes on cpuidle

こんにちは、ジョアンシーさん

コマンド「cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies」を使用すると、すべてのボードで同じ結果が得られますか?

=> はい。

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
1200000 1600000

オンデマンドとパフォーマンスを使用する頻度はどれくらいですか?

=> オンデマンドモードとパフォーマンスモードの両方で頻度は同じです。

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
1600000

Re: i.MX8MM Kernel crashes on cpuidle

すべてのボードに同じソフトウェアとハードウェアが搭載されていて、1 つのボードだけに問題がある場合は、AB テストを実行して、チップの問題かどうかを確認CAN。コマンド「 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 」を使用すると、すべてのボードで同じ結果が得られますか? また、オンデマンドとパフォーマンスを使用した場合の周波数はどれくらいですか?つまり、オンデマンドまたはパフォーマンスを設定するときに、コマンドを使用して「cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq」をチェックすると、オンデマンドとパフォーマンスは同じ CPU 周波数を共有しているかどうかがわかります。

Re: i.MX8MM Kernel crashes on cpuidle

こんにちは、ジョアンシーさん

情報をいただきありがとうございます。

カーネルはペリフェラルに対してのみ変更されており、CPU 周波数やその他の CPU 関連の設定には変更が加えられていません。当社のデバイスの多くは正常に起動し、動作CAN。現時点では、1 日間実行した後にクラッシュするデバイスは 1 台のみです。

scaling_available_frequencies の結果は次のとおりです。

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
1200000 1600000

Re: i.MX8MM Kernel crashes on cpuidle

カーネルで何を変更しますか？ imx8mm のデフォルト周波数は 1.2Ghz SO、ボードをデフォルトとして起動することはできませんよね？「 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 」を実行すると何が表示されますか？ubootはinitクロックを以下のように設定します。

/arch/arm/mach-imx/imx8m/clock_imx8mm.c

カーネルの場合、利用可能なCPU周波数をdtsiファイルに設定し、cpufreqドライバは

https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/drivers/cpufreq/imx-cpufreq-dt.c

もしあなたのBSPがNXPと似ているなら、1.2Gでシステムがクラッシュするようです。添付ファイルの2.5.3 CPU周波数スケーリング（CPUFREQ）の章を参照してください。

Re: i.MX8MM Kernel crashes on cpuidle

こんにちは、ジョアンシーさん

CPUガバナーがオンデマンドモードのときにシステムがクラッシュしました。

scaling_available_governors の結果は次のとおりです。

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
conservative ondemand userspace powersave performance schedutil

Re: i.MX8MM Kernel crashes on cpuidle

システムのデフォルトのCPUガバナーは ondemand です。CPUガバナーを performance に変更してテストしたところ、システムがクラッシュしなくなりました。

> それはあなたのタイプミスですか？システムがクラッシュするのはいつですか？オンデマンドかパフォーマンスか?

コマンド「cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors」の結果を教えてもらえますか?

Re: i.MX8MM Kernel crashes on cpuidle

こんにちは@adv-johnchang

私たちは、32 MB QSPI NOR フラッシュを搭載したカスタム i.MX8M Plus DDR4 ボードを使用しています。
私たちの目標は、U-Boot、Linuxカーネル、デバイスツリー、およびinitramfs（rootfs.img）を起動することです。SD/eMMC を使用せずに、完全にQSPI フラッシュから。

U-Boot (flash.bin) まで正常に起動できましたQSPI フラッシュから。

-----Flashレイアウトと画像サイズ----------------

QSPIフラッシュサイズ: 32 MB

flash.bin (U-Boot + SPL) 約 2.4 MB
Image.gz (カーネル) ~15 MB
imx8mp-evk.dtb ~85 KB
rootfs.img 約12.6 MB

----QSPI オフセットレイアウト----------
flash.bin @ 0x00000000
画像.gz @ 0x0024D000
imx8mp-evk.dtb @ 0x010A6B00
ルートfs.img @ 0x010BB800

U-Boot環境のセットアップ

QSPI から U-Boot を起動した後、次の環境変数を設定して、フラッシュからカーネル、デバイスツリー、および initramfs をロードします。

sfプローブ0
setenv loadaddr 0x40480000 // カーネル
setenv fdt_addr 0x43000000 //dtb
setenv initrd_addr 0x43800000 //rootfs (最小限のinitramfs)
setenv kernel_comp_addr_r 0x50000000
setenv kernel_comp_size 0x04000000

QSPIフラッシュからの画像の読み取り

sf 読み取り${loadaddr} 0x0024D000 0x00E59A6F
sf 読み取り${fdt_addr} 0x010A6B00 0x00014BBA
sf 読み取り${initrd_addr} 0x010BB800 0x00C04DB0

ブートコマンド

setenv bootargs コンソール= ${console} 、 ${baudrate} earlycon= ${earlycon} 、 ${baudrate} rdinit=/dev

ブーティ${loadaddr} ${initrd_addr} ${fdt_addr}

観察された問題

カーネルの実行は開始されますが、 「カーネルを開始しています…」でハングします。
添付のカーネルブートログ（kernel_bootlog1）を参照してください。

次のブート引数を使用する場合:

setenv bootargs setenv bootargs "console=ttymxc1,115200 earlycon root=/dev/ram0 rw rdinit=/sbin/init loglevel=8"

カーネルはさらに進みますが、ブートの途中でハングします。
添付のカーネルブートログ（kernel_bootlog2）を参照してください。

参考までにカーネル DTSとカーネル defconfigを添付しました。
変更が必要な場合はお知らせください。

また、仮想アドレスでのカーネルページング要求を処理できないなどの同じエラーも発生します。これを解決してカーネルを正常に起動するための提案をお願いします。

質問:

1.カスタム i.MX8M Plus DDR4 ボード上の QSPI から initramfs を完全に起動するために、カーネル DTS に必要な推奨変更はありますか?

2. QSPI フラッシュから i.MX8MP を initramfs ベースでブートする場合、NXP が推奨する追加のブート引数はありますか?

3. カーネルが正しく起動しない理由は何でしょうか?
i.MX8MP LPDDR4 EVK で正常に動作するのと同じ手順に従い、カーネルとルートファイルシステムが QSPI フラッシュから適切に起動しました。
私たちのセットアップにおける唯一の違いはflash.binとデバイスツリーで、これらはカスタムボードの DDR 構成に応じて変更されています。

どうもありがとうございます。