t.kuramata
2024年1月18日 16時22分
お世話になっております。
再起動中にエラーとなり復帰しない症状について教えてください。
【症状】
1日に1度、Armadilloをシェルスクリプトから「shutdown -r now」で再起動するよう設定して常時稼働させていましたが、
半月～1ヵ月が経過した時点で再起動中にエラーとなり、デバッグシリアルインターフェイスから添付ファイルの内容が繰り返し出力されるのみの状態となってしまい、本来の動作だけでなくログインも出来ない状態となります。
電源を再投入すると解消され通常通り動作を開始します。
【Armadilloの用途および設定】
RS485通信で取得したデータをSIMカードのモバイル通信で転送する用途で使用しています。
またoverlayfsを利用した電源断からの保護機能を設定しています。
原因および対策方法を知りたく、お願いいたします。
| ファイル | ファイルの説明 |
|---|---|
| 再現時のデバッグシリアルインターフェイス出力内容.txt | 再起動のエラー中にデバッグシリアルインターフェイスから出力される内容。同様の内容が継続して出力される |
コメント
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 の際の再起動はいつもよりちょっと遅くなる程度以外思い浮かびません）
よろしくお願いします。
t.kuramata
2024年2月28日 9時00分
連続試験を行い調査に進展がありましたので、ご連絡いたします。
以下調査は2分毎に再起動する設定の元、シリアルコンソールの表示から異常有無を確認しました。
(1) v4.9-x1-at22の場合
・RS485通信や電源断からの保護機能(overlayfs)の設定に限らず再現した
・RS485通信を使用した場合は再現する頻度が高い
・panic_on_rcu_stallを設定すると再現しない（シャットダウン中の異常発生時にリセットされ復帰する）
・再現する頻度は
panic_on_rcu_stallを設定（再現ゼロ）< overlayfsなし < overlayfsあり <<<<<< RS485通信使用
(2) v4.9-x1-at31の場合
・いずれの場合でも再現なし
市場で動作中のArmadilloには、暫定対策としてpanic_on_rcu_stallを設定しました。
今後使用するArmadilloには、恒久対策としてv4.9-x1-at31の使用を予定します。
（万が一、v4.9-x1-at31でも再現した場合はpanic_on_rcu_stallを設定する）
一点、v4.9-x1-at31で再起動中に時間がかかった場合があり、その際のシリアルコンソールの内容を添付します。
もし対処すべき問題である場合は対応方法をご教示願います。
以上、よろしくお願いいたします。
| ファイル | ファイルの説明 |
|---|---|
| at31が再起動で躓いた.txt |
at_dominique.m…
2024年2月28日 10時01分
t.kuramataさん、
マルティネです。
報告ありがとうございます！
> (2) v4.9-x1-at31の場合
> ・いずれの場合でも再現なし
やっぱり rs485関係で、at31 に入ったドライバの修正の影響でその問題も修正されましたね。
よかったです！
（ちなみに私は手元の G3L で4日間再起動をループさせても再現できなかったが、rs485 の通信が接続せずまったくない状態なのでそこで何かの差出てるかもしれません…）
> 一点、v4.9-x1-at31で再起動中に時間がかかった場合があり、その際のシリアルコンソールの内容を添付します。
> もし対処すべき問題である場合は対応方法をご教示願います。
報告ありがとうございます。
linux 6.1 へ移植している作業で確認していた問題ですが、v4.9-x1-at31 でも発生されますね。
この問題も再起動中に panic して、watchdog によっていずれ再起動されますが poweroff の際に発生した場合も再起動してしまう問題なので修正したいと思います。
再起動するだけのであれば少し遅くなるだけなので無視していただいて問題ありません。
（linux 6.1 と似たような修正はできると思いますので、確認でき次第に修正して、恐らく3月までに at32 のカーネルをリリースすることになります…必要でしたらその前にパッチとして提供できますので聞いてください）
よろしくお願いします。
t.kuramata
2024年2月28日 15時45分
ご回答ありがとうございます。
> やっぱり rs485関係で、at31 に入ったドライバの修正の影響でその問題も修正されましたね。
本件を締めるにあたりat22からat31への移行で問題が解消された要因について貴社側の見解を得たいため今一度、
①本件は何が原因で②どのバージョンにて③何が対策された、ことで解消となったのか教えていただけますでしょうか。
> 必要でしたらその前にパッチとして提供できますので聞いてください
パッチは不要です。ありがとうございます。at32のリリースを待って恒久対策に仕掛かることとします。
よろしくお願いいたします。
at_dominique.m…
2024年2月28日 16時18分
> 本件を締めるにあたりat22からat31への移行で問題が解消された要因について貴社側の見解を得たいため今一度、
> ①本件は何が原因で②どのバージョンにて③何が対策された、ことで解消となったのか教えていただけますでしょうか。
すみません、今回の不具合の原因までは分かりません。
4.9-at30 までに RS485 において、通信できなくなる不具合があったためその RS485 を制御するドライバ（drivers/tty/serial/imx.c) を新しいカーネルから at31 にバックポートしました（linux 5.10 で不具合が発生してなかったとのことです）。
以下のコミットです：
https://github.com/atmark-techno/linux-4.9-at/commit/be041bbaff8d8a696b…
https://github.com/atmark-techno/linux-4.9-at/commit/64f508d31f66f9dab6…
https://github.com/atmark-techno/linux-4.9-at/commit/3f2db78e7032c2ed1c…
なので、at31 とそれ以前のバージョンで RS485やRS232のまわりのコードがかなり変わってしまって、「変更あるので通信の疑いがあるならもしかしたら」と考えた次第です。
> > 必要でしたらその前にパッチとして提供できますので聞いてください
>
> パッチは不要です。ありがとうございます。at32のリリースを待って恒久対策に仕掛かることとします。
了解しました。
よろしくお願いします。
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」を記載してください。
それでまた再現してしまっても結果的に再起動されます。
よろしくお願いします。