ふるた技工所(てっこうしょ)

とりとめもなく書く。"reboot aging" と呼ぶテストをしている。前に仕事をしていた先で使っていたいわゆるローカル用語だと思う。reboot をひたすら繰り返すテストだ。

組み込み開発でのやり方はいくつかあった。シリアルコンソールに teraterm を繋ぎ、マクロで login - reboot を繰り返す。watchdog を発動する様に仕向けて reboot する。スイッチ操作相当のことをして reboot する。

普通にシャットダウンしてリブートするのではないか？ 恐らくそう思う人が多いと思う。



やってみると機能不全で立ち上がる。途中でハングする。ログが溢れて動かなくなる。想定以上に Flash Memory が損耗する。といった問題が露見することがある。

QEMU 上で RaspberryPi OS Trixie を動かすことを試していて、reboot ができるように実装を進めていた。どうも「reboot するとハングアップしてしまうのでは？」という事象に遭遇する。初めのうちは「何かの見間違いか操作ミス？」と思っていた。手操作で 2, 3 回遭遇したあたりで、繰り返しテストを自動化しようと思い始める。

• /etc/init.d/reboot-agingとして配置するスクリプト
• /root/reboot-aging/reboot-aging.sh として配置するスクリプト

スクリプトだけで reboot を繰り返す様にした。

先に出したスクリーンショットに類似のハングアップ状態が 3 回得られた。様子を見ようと QEMU monitor の切り替え操作 [Ctrl]-[a] [c] を繰り返していると、kernel panic back trace が現れる。

dwc_otg_handle_common_intr, dwc_otg_common_irq で何か悪いことが起きたのか。DWC (Design Ware Core) USB-OTG ドライバですか... 「またお前か」という既視感。

デバッグはある程度進めていて、DWC の platform_driver の shutdown method が実装されていないのが原因だと推定している。shutdown method にて少なくとも割り込みマスク(割り込み発生を止める設定)が必要だということまで分かっている。

推定を元に dirty hack な修正を実験中だ。

Linux の kernel driver は open source で優秀なエンジニアが書いて、レビューをして、テストをしているから、安定して動くというのは幻想だ。実際はちょっと激しく叩くと問題が露見する。

ログとか Flash Memory の問題は OS が立ち上がってからの処理なので対応は比較的容易だ。reboot を繰り返して出てくる悩ましい問題の例は

• 初期化に問題があって機能不全
  • Clock, Power domain 制御に必要な待ち時間が確保されていない(Linux kernel 内の clk, regulator class driver はある程度考慮されている)
  • 割り込み処理の準備が整っていないのに割り込みを発生させて handler が動いてしまう、あるいは動かずに IRQ storm 状態に陥る
  • DMA controller 連系などがあるのに連系先の準備ができていない状態で動作開始
  • Firmware download のタイミングが遅く、仮 firmware で動いてしまう
• 終了処理に問題があって望ましくない終了状態
  • device context を破棄してしまったのに割り込み処理をしてしまう
  • 道連れに止めきれなかった timer, work, thread が動いて片付け終わった領域・レジスタを操作してしまう
  • 連系先は既に止まっているのに使おうとする
  • 入出力端子が望ましい状態では無く、電圧・電流が出たまま

と言ったところだろうか。今時は階層構造の整備, device tree による構造表現が整備されているので、問題は起きにくくなっている。

なんだな、除夜の鐘をつく回数 108 回よりは多く連続 reboot できてほしいものだ。