Armadilloフォーラム

再起動中にエラーとなり電源再投入しないと復帰しない場合がある

t.kuramata

2024年1月18日 16時22分

お世話になっております。
再起動中にエラーとなり復帰しない症状について教えてください。
【症状】
1日に1度、Armadilloをシェルスクリプトから「shutdown -r now」で再起動するよう設定して常時稼働させていましたが、
半月~1ヵ月が経過した時点で再起動中にエラーとなり、デバッグシリアルインターフェイスから添付ファイルの内容が繰り返し出力されるのみの状態となってしまい、本来の動作だけでなくログインも出来ない状態となります。
電源を再投入すると解消され通常通り動作を開始します。
【Armadilloの用途および設定】
RS485通信で取得したデータをSIMカードのモバイル通信で転送する用途で使用しています。
またoverlayfsを利用した電源断からの保護機能を設定しています。

原因および対策方法を知りたく、お願いいたします。

ファイル ファイルの説明
再現時のデバッグシリアルインターフェイス出力内容.txt 再起動のエラー中にデバッグシリアルインターフェイスから出力される内容。同様の内容が継続して出力される
コメント

at_dominique.m…

2024年1月31日 11時43分

t.kuramataさん、

お世話になっています、
マルティネです。

返事が遅くなってすみません。

> 再起動中にエラーとなり復帰しない症状について教えてください。
> 【症状】
> 1日に1度、Armadilloをシェルスクリプトから「shutdown -r now」で再起動するよう設定して常時稼働させていましたが、
> 半月~1ヵ月が経過した時点で再起動中にエラーとなり、デバッグシリアルインターフェイスから添付ファイルの内容が繰り返し出力されるのみの状態となってしまい、本来の動作だけでなくログインも出来ない状態となります。

欲張りのは承知の上で聞いてみますが、再現した際のシリアルコンソール出力はないですね?
最初のエラーメッセージが異なる場合がありますので、あれば助かります。
(なければ仕方ありません、こちらで再現できる環境を準備しておきます。説明では15-30回の再起動で発生するので、条件が揃えれば再現できるはずです)

> 【Armadilloの用途および設定】
> RS485通信で取得したデータをSIMカードのモバイル通信で転送する用途で使用しています。
> またoverlayfsを利用した電源断からの保護機能を設定しています。

使用しているカーネルバージョンを教えていただけ増すか?
4.9系のカーネルでしたら、最新の v4.9-x1-at31 で RS485 関係の不具合を修正しましたので、もしかしたらそれで解決されたかもしれません。
(修正したかった不具合と違う現象なので、確信はまったくないですが…すでに修正された不具合でしたら時間の節約になりますので確認できれば助かります)

> 原因および対策方法を知りたく、お願いいたします。

G3L では再起動時に i2c で通信をしていますので、その通信ができなかった可能性もありますが、その場合は恐らく再起動時に何か別のメッセージが表示されるはずですのでそこから確認したいですね。

対策としてはとりあえず、「INFO: rcu_preempt self-detected stall on CPU」のメッセージがありますので、
kernel.panic_on_rcu_stall の設定を行えば watchdog で再起動されますので回避になると思います。
/etc/sysctl.d/panic.conf 等のファイルを生成して、「kernel.panic_on_rcu_stall=1」を記載してください。
それでまた再現してしまっても結果的に再起動されます。

よろしくお願いします。

t.kuramata

2024年2月1日 11時31分

ご回答ありがとうございます。

> 再現した際のシリアルコンソール出力はないですね?
再現時のシリアルコンソール出力ありましたので添付します

> 使用しているカーネルバージョンを教えていただけ増すか?
v4.9-x1-at22を使用していいます。最新の v4.9-x1-at31で試してみます

> /etc/sysctl.d/panic.conf 等のファイルを生成して、「kernel.panic_on_rcu_stall=1」を記載してください。
試してみます。下記手順で問題ないでしょうか?
① /etc/sysctl.d/panic.confをファイル生成
② ①ファイル内にkernel.panic_on_rcu_stall=1を記述
③ 再起動(設定を適用のため)

当方で判明した新たな情報を記載します。
・再起動(=シャットダウン+起動)の内、シャットダウン処理で停止する
・overlayfsを利用した電源断からの保護機能(overlayfs)を有効化時のみ再現する
・RS485通信を利用するソフトウェア(※1)を使用すると再起動時に再現する
・SIM/LANケーブルの有無に関わらず再現する →ネットワーク接続は関係ない

上記試験は、
①単にRS485通信で送受信するNode.jsプログラムをArmadillo起動時に実行開始させ、
②シェルスクリプトから起動後5分後に再起動するよう設定することで、
RS485通信中に再起動を繰り返す試験から確認しました。
約数分~12時間以内には再現します。

今こちらでは再起動前にシリアルポートを閉じることで解消されないか確認しています。
よろしくお願いいたします。

ファイル ファイルの説明
Armadillo試験.zip

at_dominique.m…

2024年2月1日 13時07分

t.kuramataさん、

> > 再現した際のシリアルコンソール出力はないですね?
> 再現時のシリアルコンソール出力ありましたので添付します

ありがとうございます。
最初から stall on cpu ですね…
"eth0: MDIO read timeout" も気になりますが、後で教えていただいたネットワークが関係ないとのことでしたらこちらはおそらく別の原因による影響ですね。

> > 使用しているカーネルバージョンを教えていただけ増すか?
>
> v4.9-x1-at22を使用していいます。最新の v4.9-x1-at31で試してみます

お手数ですがお願いします。

> > /etc/sysctl.d/panic.conf 等のファイルを生成して、「kernel.panic_on_rcu_stall=1」を記載してください。
> 試してみます。下記手順で問題ないでしょうか?
> ① /etc/sysctl.d/panic.confをファイル生成
> ② ①ファイル内にkernel.panic_on_rcu_stall=1を記述
> ③ 再起動(設定を適用のため)

はい、これであっています。
③ は再起動か「sysctl -p /etc/sysctl.d/panic.conf」でもいいです。適用された後に「sysctl kernel.panic_on_rcu_stall」で値を表示して確認できます。

> 当方で判明した新たな情報を記載します。
> ・再起動(=シャットダウン+起動)の内、シャットダウン処理で停止する
> ・overlayfsを利用した電源断からの保護機能(overlayfs)を有効化時のみ再現する
> ・RS485通信を利用するソフトウェア(※1)を使用すると再起動時に再現する
> ・SIM/LANケーブルの有無に関わらず再現する →ネットワーク接続は関係ない

大変助かります、ありがとうございます。

> 上記試験は、
> ①単にRS485通信で送受信するNode.jsプログラムをArmadillo起動時に実行開始させ、
> ②シェルスクリプトから起動後5分後に再起動するよう設定することで、
> RS485通信中に再起動を繰り返す試験から確認しました。
> 約数分~12時間以内には再現します。
>
> 今こちらでは再起動前にシリアルポートを閉じることで解消されないか確認しています。

了解しました。
勘違いしていないかの確認のために改めて言い直します:
* overlayfs 有効しないと再現しません。
* RS485 通信ありの場合で再現してますが、これからなしでも再現するかを確認します。
* v4.9-x1-at22 で再現していますが、これから v4.9-x1-at31 も確認します。
* panic on rcu の sysctl もこれから確認します。

確認する項目が多いので順番にお願いします。

こちらに関しては:
- v4.9-x1-at22 と v4.9-x1-at31 の差分を確認してみて、RS485 の変更以外にあまり期待できる修正がないことを確認しました。
- Armadillo IoT G3L を設定して再現できるかの確認作業に入ります。

引続きよろしくお願いします。

t.kuramata

2024年2月1日 14時11分

ご回答ありがとうございます。

> 勘違いしていないかの確認のために改めて言い直します:
> * overlayfs 有効しないと再現しません。
→その通りです

> * RS485 通信ありの場合で再現してますが、これからなしでも再現するかを確認します。
→Armadillo-IoT G3LのCON4に配線をはずすと再現しないことを確認済みです。
 ちなみに全二重通信設定をしています(optargs imx.rs485_uart2=0x13,0,0)
 先程添付したNode.jsプログラム内でのRS485通信の有無やポートの開閉処理に着目して確認しています

> * v4.9-x1-at22 で再現していますが、これから v4.9-x1-at31 も確認します。
→その通りです

> * panic on rcu の sysctl もこれから確認します。
→その通りです
 早速kernel.panic_on_rcu_stall=1を設定後、異常が発生しましたが、停止することなく期待通り再起動したかもしれません。
 その際のシリアルコンソールの内容を添付しますがいかがでしょうか。引き続き確認します

よろしくお願いいたします。

ファイル ファイルの説明
kernel.panic_on_rcu_stall=1設定で効果ありか.txt

t.kuramata

2024年2月6日 11時04分

調査に進展がありましたので、ご連絡いたします。

* overlayfs 有効しないと再現しません。
→今のところ再現していません

* RS485 通信ありの場合で再現してますが、これからなしでも再現するかを確認します。
→RS485通信なしでも再現しました。よって単に再起動を繰り返すだけでも再現するかもしれません。
 ただしRS485通信ありと比べて非常に低頻度で再現は1回のみのため、引き続き調査します。

* v4.9-x1-at22 で再現していますが、これから v4.9-x1-at31 も確認します。
→こちらはインストールディスクの作成に時間を要しており調査中です

* panic on rcu の sysctl もこれから確認します。
→現時点で再現ゼロであり効果が出ています!

何か新しい情報はございますでしょうか。
よろしくお願いいたします。

at_dominique.m…

2024年2月6日 13時31分

t.kuramataさん、

マルティネです。

状況報告ありがとうございます。

> * RS485 通信ありの場合で再現してますが、これからなしでも再現するかを確認します。
> →RS485通信なしでも再現しました。よって単に再起動を繰り返すだけでも再現するかもしれません。
>  ただしRS485通信ありと比べて非常に低頻度で再現は1回のみのため、引き続き調査します。

こちらで v4.9-x1-at31 のカーネルで、 overlayfs 有効だけ(RS485 設定してない)状態で一日連続再起動させましたが再現できてなかったので RS485 必要でしょうとおもって実験を止めてましたが、そちらで v4.9-x1-at22 で再現できましたね。
RS485 のドライバと普通のシリアルコンソールのドライバは同じなので、再現率が下がるとのことでこのドライバの影響の可能性はまだ高いと考えています。
それでしたら v4.9-x1-at31 で修正されてますので、こちらで v4.9-x1-at22 でもう一度確認してみます。

> * v4.9-x1-at22 で再現していますが、これから v4.9-x1-at31 も確認します。
> →こちらはインストールディスクの作成に時間を要しており調査中です

その確認もお待ちしています。

> * panic on rcu の sysctl もこれから確認します。
> →現時点で再現ゼロであり効果が出ています!
>
> 何か新しい情報はございますでしょうか。

ワークアラウンドとしては問題ないと思いますが、カーネル更新で修正できる問題でしたら都合のいいタイミングで更新した方がいいと思いますので、確認の引き続きよろしくおねがいします。

よろしくお願いします。

t.kuramata

2024年2月6日 14時36分

ご回答ありがとうございます。

> RS485 のドライバと普通のシリアルコンソールのドライバは同じなので、再現率が下がるとのことでこのドライバの影響の可能性はまだ高いと考えています。
> それでしたら v4.9-x1-at31 で修正されてますので、こちらで v4.9-x1-at22 でもう一度確認してみます。
よろしくお願いします。

> ワークアラウンドとしては問題ないと思いますが、カーネル更新で修正できる問題でしたら都合のいいタイミングで更新した方がいいと思いますので、確認の引き続きよろしくおねがいします。
既に客先で稼働中のArmadilloに対してはpanic_on_rcu_stallの設定による対応を考えておりますが、設定による別機能への影響など特筆すべき影響がありましたらご教示願います。
恒久的には最新版のカーネル使用を方向も検討してみます。

v4.9-x1-at31の確認の方も進めます。
よろしくお願いします。

at_dominique.m…

2024年2月6日 15時08分

> 既に客先で稼働中のArmadilloに対してはpanic_on_rcu_stallの設定による対応を考えておりますが、設定による別機能への影響など特筆すべき影響がありましたらご教示願います。

設定の名前の通り、RCU stall のワーニングが発生したら panic しますので、本不具合以外に無害な RCU stall が発生した場合に再起動してしまいます。
通常では RCU stall ワーニングが発生しないはずですが、Linux はリアルタイムではないのでまれにタスクが遅くなって発生する可能性はあります。
この設定を変更したことで RCU stall が今までより多くなりませんので、自分のアプリケーションで発生することがなければ(単純に、起動してある armadillo の dmesg を確認して RCU stall のメッセージが想定どおりにない)、適切なワークアラウンドだと考えています。
少なくとも、まれの予定外の再起動は armadillo が復帰しないことより好ましいと思います。

それ以外は影響ありません(panic の際の再起動はいつもよりちょっと遅くなる程度以外思い浮かびません)

よろしくお願いします。