k.kumasaka
2020年6月12日 16時47分
Armadillo-X1の再起動が3～6時間ごとに発生します。
使用LinuxはLinux armadillo 3.14.79-at10 #39 SMP PREEMPT Fri Dec 6 14:14:34 JST 2019 armv7l GNU/Linux です。
解決方法はご存知ないでしょうか?
コメント
y-full
2020年6月16日 18時27分
お世話になります
k.kumasakaの代わりにアカウントy-fullがお答えします
アプリケーションは開発しています
ソフトウェアウォッチドッグタイマーとは何を指していますでしょうか、X1に実装しているウォッチドッグの操作方法がわからなかったので使用していません
また、アプリケーションはphp、bashスクリプト、c言語で30本弱動作させています
なお本日は6/16 5:27ごろに発生しました、以降は発生していません
発生頻度は不確定かと思われます
また発生時と思われるkern.logおよびsyslog.1およびdmeagを送付いたします
なにかお分かりになるようでしたら、ご助言願います
| ファイル | ファイルの説明 |
|---|---|
| kern.log | |
| syslog1.log | |
| dmesg.log |
ktgoto
2020年6月17日 9時58分
後藤です。
> お世話になります
> k.kumasakaの代わりにアカウントy-fullがお答えします
>
> アプリケーションは開発しています
> ソフトウェアウォッチドッグタイマーとは何を指していますでしょうか、X1に実装しているウォッチドッグの操作方法がわからなかったので使用していません
> また、アプリケーションはphp、bashスクリプト、c言語で30本弱動作させています
ソフトウェアウォッチドッグタイマーは、CPUのウォッチドッグタイマーとは別にカーネルが提供するソフトウェアによるウォッチドッグタイマーです。
カーネルのコンフィギュレーションで CONFIG_SOFT_WATCHDOG を有効にすると使用可能で、リフレッシュに失敗するとリセットではなく再起動が行われます。
> なお本日は6/16 5:27ごろに発生しました、以降は発生していません
> 発生頻度は不確定かと思われます
>
> また発生時と思われるkern.logおよびsyslog.1およびdmeagを送付いたします
> なにかお分かりになるようでしたら、ご助言願います
ログの添付ありがとうございます。内容確認してみます。
確認なんですが、アプリケーションの機能として異常を検知して再起動するような処理は特に実装していないにも関わらず、意図しない再起動が行われるという理解で合っていまでしょうか？
ktgoto
2020年6月17日 18時27分
後藤です。
> アプリケーションで異常を検知して再起動する処理は入れていますが
> アプリーケーションの再起動のみ実施しており、証拠も残すようにしています
> OSまで再起動するような機能は入れておりません
ご説明ありがとうございます。
＠ｔの佐藤様が kern.log に関してコメントされていますが、kern.log に関して別の観点でコメント致します。
kern.log に以下のログが出力されており、カーネルのマジック SysRq キーが動いた形跡がありました。
| Jun 16 12:42:59 armadillo kernel: SysRq : HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) show-blocked-tasks(w)
マジック SysRq キーの詳細は下記の URL をご参照ください。
http://archive.linux.or.jp/JF/JFdocs/Remote-Serial-Console-HOWTO/securi…
https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html
Armadillo-X1 では、シリアルコンソールにブレークを送信後、対応する文字を書き込むことでマジック SysRq キーを利用でき、再起動等の操作ができます。未対応の文字を書き込むと上記のような HELP が出力されます。
意図的にマジック SysRq キーを使用したということでなければ、アプリが意図せずマジック SysRq キーで再起動操作と認識されるような文字シーケンスをシリアルコンソールに書き込んでしまっている可能性があるかもしれません。
マジック SysRq キーは、カーネルのコンフィギュレーションで無効にできますので、マジック SysRq キーを無効にした状態で評価してみるのは如何でしょうか？
----- メニューコンフィグ -----
Kernel hacking --->
[ ] Magic SysRq key
[ ] KGDB: kernel debugger ---> <= こちらを先に無効にする。
------------------------------
以上です。
at_makoto.sato
2020年6月17日 15時51分
佐藤です。
いただいたkern.logの中に以下のような箇所があります。
-----
(省略)
Jun 14 14:09:50 armadillo kernel: Kernel BUG at 800c2bc8 [verbose debug info unavailable]
Jun 14 14:09:50 armadillo kernel: Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
Jun 14 14:09:50 armadillo kernel: Modules linked in:
Jun 14 14:09:50 armadillo kernel: CPU: 0 PID: 22977 Comm: soilrecv Not tainted 3.14.79-at10 #39
(省略)
-----
soilrecvというアプリケーションが原因のようにみえますが、これはご自身で開発されたアプリケーションでしょうか。
もし、そうであれば、今一度soilrecvプログラムに問題がないか確認してみるとよいかもしれません。
ktgoto
2020年6月17日 19時52分
後藤です。
> soilrecvはこちらで作成したアプリケーションですが
> おそらくノイズによるもので、改修済みにしているのですが
> まだ、なにかあるのかしれませんので調査してみます、
kern.logに出力されていたカーネルの Oops ですが、soilrecvの
問題ではなく3.14カーネルのUARTドライバdrivers/tty/serial/imx.c
の不具合っぽいです。
UARTドライバにimx_uart_dma_init()というDMA転送の初期化を
行う関数があり、この関数内でDMA転送用の領域を確保しています
が、領域の確保に失敗した際に後処理として呼び出している
imx_uart_dma_exit()で確保していない領域をfreeしてしまって
いるようです。
4.9カーネルでは対策されているようですが、3.14カーネルでずっと
評価をされており簡単にバージョンアップできないということであれば、
＠ｔさんにパッチをリリースしてもらうのが良いかもしれません。
> これが理由でOSが再起動しているということでしょうか
> ちなみにtaintedメッセージの後にあるのはスタックとレースと、バックログが記述されているといことでよろしいでしょうか
>
> 再起動している時間とずれているような気がするのですが
> どのような因果関係が考えられるか、ご教授願えますでしょうか
カーネル Oops が出力された後、再起動したかどうかは kern.log から
は判断できませんでした。
ただ、記載されているよう再起動時間とカーネル Oops が出力されている
時間がズレているので、議論している再起動問題とは別問題の気がします。
以上です。
at_mizo
2020年6月18日 13時29分
溝渕です。
> 稼働中のメモリの使用量が減り続けているのですが
> キャッシュクリーンアップやphpのガーベージが間に合ってないのかもしれません
> もしメモリが足りなくなった時の3系カーネルの挙動はどうなるでしょうか、ログを吐いたりはしないでしょうか
状況によります。ログを吐ける場合もあります。
まずどのメモリが減っているか次第なのですが、Linuxは未使用メモリをCache
に使うので、稼動時間が長くなるとほぼ100%のメモリを使うはずです。この場
合、実際にはメモリは枯渇していません。
Cache等一時的に使われる以外のメモリが不足した場合、アプリケーションは
メモリの確保に失敗します。この場合にログを吐くかどうかはアプリケーショ
ン次第です。
Over Commitしているメモリが使えないにメモリが枯渇している場合や、
kernel内でメモリの確保ができない場合はOOM-Killerが走るなどすると思いま
す。この場合はほぼログが吐かれます。
at_mizo
2020年6月18日 13時56分
溝渕です。
> PHP常駐プロセス等はプロセスが死ぬ程度だという認識で大丈夫でしょうか
OOM-Killerが終了させるプロセスはメモリの確保に失敗したプロセスではあり
ません。確かメモリを多く使っているプロセスが終了の対象になったと思いま
す。
余談ですが、procから任意のプロセスをOOM-Killerの対象外にしたり、終了さ
せられる優先度の変更等ができたと思います。
> この場合プロセス管理をしていますので、アプリケーションの再起動を行いますので
> メモリが減ったぐらいではOS再起動まではいかないということですね
絶対に大丈夫とは言えないのですが、OSの基本的なポリシーとして自身が動作
できなくなることは極力避けるようにします。
y-full
2020年8月5日 17時25分
カーネル4.9を試してみる方向で進んでおり、カーネルを作成し、デバイスツリーをカスタマイズしたのですが
追加したgpioが/sys/class/gpio下に作成されません
デバイスツリーの設定値はカーネル3.14で設定していたものを転用しているのですが
設定値が間違っていないでしょうか、ご教授ください
添付armadillo_x1.dtsの277行以下に追記しています
ハードウェアはカーネル3.14で動作していたものです
| ファイル | ファイルの説明 |
|---|---|
| armadillo_x1.dts |
at_akihito.irie
2020年8月6日 11時17分
入江です。
いくつか確認させてください。
> カーネル4.9を試してみる方向で進んでおり、カーネルを作成し、デバイスツリーをカスタマイズしたのですが
> 追加したgpioが/sys/class/gpio下に作成されません
これは起動時に自動的に/sys/class/gpio下にgpioディレクトリが作成されることを想定されていますか？
それとも起動後に手動でexportして作成されることを想定されていますか？
> デバイスツリーの設定値はカーネル3.14で設定していたものを転用しているのですが
> 設定値が間違っていないでしょうか、ご教授ください
添付いただいたデバイスツリーはカーネル3.14では想定通りの動作はしましたでしょうか？
at_makoto.sato
2020年6月12日 18時21分
佐藤です。
何かご自身で開発されたアプリケーションなどを動作させていますでしょうか。
/var/log/syslog や /var/log/messages などに再起動発生時のログなど出力されてますでしょうか。