h_akiyama046
2019年12月12日 19時53分
お世話になっております。
Armadillo-840を使用しています。
現在、2個のArmadillo-840で不具合動作(現象)を起こしています。
<不具合動作(現象)>
1.ARMADILLO-840の起動時間が遅い+起動中に再起動する
正常品と不具合品の起動ログを比較確認した結果、相違点がありました。
1-①[sched_delayed] sched: RT throttling activated
1-②load decoder firmware: failed
また、1/3~1/2の確率で、下記ログが表示された後に、再起動する
1-③rebooted by watchdog timedout.
2.ARMADILLO-840の起動時間が遅い
正常品と不具合品の起動ログを比較確認した結果、相違点がありました。
2-①[sched_delayed] sched: RT throttling activated
2-②load decoder firmware: failed
<質問事項>
・このログは、どのような意味ですか?
・何が原因で、このような症状になりますか?
・対策方法、対策手段は?
以上、宜しくお願いします。
コメント
h_akiyama046
2019年12月12日 20時51分
溝渕様、早速の回答ありがとうございます。
まずは、下記理解で正しいでしょうか?
・[sched_delayed] sched: RT throttling activated
<意味>
一定時間内にタスクが実行できなかったことを示しています。
<原因>
context switchが実行できない状態になっているのではないかと思います。
<対策方法、対策手段>
現時点では、原因がわからない
・load decoder firmware: failed
<意味>
AVコーデックミドルウェアのファームウェアが無いことを示しています。
<原因>
AVコーデックミドルウェアがフラッシュメモリに書き込まれていないのが原因です。
<対策方法、対策手段>
AVコーデックミドルウェアをフラッシュメモリに掛き込むことによって解決できると思います。
それでは、
1.rebooted by watchdog timedout. は?
2.起動時間が遅いと書きましたが、起動後の入力に対する出力の反応も遅いのですが、何が
考えられますか?
Armadillo-840を弊社製の拡張基板に接続し、SWの入力やLED、LCD等への出力がありますが、
例えばSW入力に対する、LED点灯やLCD表示するまでの時間も長いのです。
弊社製の拡張基板に異常が有るのでは?と思い、ACアダプターから電源供給し、起動しましたが、
不具合症状は改善しませんでした。
3.「2.ARMADILLO-840の起動時間が遅い」という方は、不具合動作が再現しなくなりました。
・[sched_delayed] sched: RT throttling activated
⇒起動ログにはありません
・load decoder firmware: failed
⇒load decoder firmware: acm_h264dec: H.264 Decoder of AV Codec Middleware
acm_aacdec: AAC Decoder of AV Codec Middleware
done と起動ログに表示されます。
よって、AVコーデックミドルウェアがフラッシュメモリに書き込まれていないという原因では
ないようです。
4.昨年も同じようなものが発生しており、
①御社から提供していただいたイメージファイルに書き換えても同様な問題が発生
②その後、弊社のイメージファイルに書き換えても同様な問題が発生
頻度は100%でした。
以上、宜しくお願い致します。
h_akiyama046
2019年12月12日 21時09分
先程、投稿した3.について、もう少し詳しく書くと、
①弊社製の拡張基板にArmadillo-840が接続された状態・・・不具合症状有り
↓
②拡張基板からArmadillo-840を取り外す
↓
③Armadillo-840単体で確認・・・不具合症状あり
※ACアダプターからDC5Vを供給
↓
④弊社製の拡張基板に再度取り付ける・・・不具合症状なし
という状態です。
また、再現しなくなっているということを考えた場合、基板への部品実装不良、半田付け不良やパターンの断線ということも
考えられるのではないでしょうか?
以上、宜しくお願い致します。
at_mizo
2019年12月12日 21時15分
溝渕です。
> まずは、下記理解で正しいでしょうか?
> ・[sched_delayed] sched: RT throttling activated
> <意味>
> 一定時間内にタスクが実行できなかったことを示しています。
> <原因>
> context switchが実行できない状態になっているのではないかと思います。
> <対策方法、対策手段>
> 現時点では、原因がわからない
>
> ・load decoder firmware: failed
> <意味>
> AVコーデックミドルウェアのファームウェアが無いことを示しています。
> <原因>
> AVコーデックミドルウェアがフラッシュメモリに書き込まれていないのが原因です。
> <対策方法、対策手段>
> AVコーデックミドルウェアをフラッシュメモリに掛き込むことによって解決できると思います。
正しいです。
> 1.rebooted by watchdog timedout. は?
ウォッチドッグタイマーによるリセットが発生しています。
Armadillo-840では、kernel threadによって、ウォッチドッグタイマーのkick
を行っています。何かしらの理由でkickできない状態となっているのがリセッ
トの原因です。
> 2.起動時間が遅いと書きましたが、起動後の入力に対する出力の反応も遅いのですが、何が
> 考えられますか?
何かの処理に追われている可能性は考えられます。これは、以下のメッセージ
が出力されるのと同じ原因である可能性もあります。
> ・[sched_delayed] sched: RT throttling activated
> Armadillo-840を弊社製の拡張基板に接続し、SWの入力やLED、LCD等への出力がありますが、
> 例えばSW入力に対する、LED点灯やLCD表示するまでの時間も長いのです。
> 弊社製の拡張基板に異常が有るのでは?と思い、ACアダプターから電源供給し、起動しましたが、
> 不具合症状は改善しませんでした。
上記、御社製の拡張基板を外し、Armadillo-840単体で、出荷状態のイメージファ
イルで起動した状態であるという認識で良いでしょうか。
> 3.「2.ARMADILLO-840の起動時間が遅い」という方は、不具合動作が再現しなくなりました。
> ・[sched_delayed] sched: RT throttling activated
> ⇒起動ログにはありません
> ・load decoder firmware: failed
> ⇒load decoder firmware: acm_h264dec: H.264 Decoder of AV Codec Middleware
> acm_aacdec: AAC Decoder of AV Codec Middleware
> done と起動ログに表示されます。
> よって、AVコーデックミドルウェアがフラッシュメモリに書き込まれていないという原因では
> ないようです。
上記、同一個体、同一ソフトウェアでの再現結果でしょうか。
> 4.昨年も同じようなものが発生しており、
> ①御社から提供していただいたイメージファイルに書き換えても同様な問題が発生
> ②その後、弊社のイメージファイルに書き換えても同様な問題が発生
> 頻度は100%でした。
もし、Armadillo-840単体で、全ソフトウェア(Hermit, Linuxの起動オプショ
ン, Linuxカーネル, ユーザランド, config領域)が出荷状態でも問題が発生す
る場合は、該当個体に問題がある可能性が高いです。
以下の内容をご確認の上、Webフォームからお問い合わせをお願い致します。
[製品保証について]
https://users.atmark-techno.com/support/warranty
以上、ご確認の程宜しくお願いいたします。
h_akiyama046
2019年12月13日 10時41分
> 1.rebooted by watchdog timedout. は?
⇒ウォッチドッグタイマーによるリセットが発生しています。
Armadillo-840では、kernel threadによって、ウォッチドッグタイマーのkick
を行っています。何かしらの理由でkickできない状態となっているのがリセッ
トの原因です。
⇒①何かしらの理由として考えられることを教えてください?
②ボード自体が要因(実装部品の破壊、パターン断線、半田付け不良等)でしょうか?
或いはソフトウェア(イメージファイル)でしょうか?
仮に、ソフトウェア(イメージファイル)とすると、数的にもっと発生すると考えますが。。。
③イメージファイルの書込みに失敗しているという事は、考えられますか?
> 2.起動時間が遅いと書きましたが、起動後の入力に対する出力の反応も遅いのですが、何が
> 考えられますか?
⇒何かの処理に追われている可能性は考えられます。これは、以下のメッセージが出力される
のと同じ原因である可能性もあります。
> ・[sched_delayed] sched: RT throttling activated
⇒①何かの処理とは? 考えられることを教えてください。
②ウォッチドックダイマーによるリセットが発生する事と関連性はありますか?
> Armadillo-840を弊社製の拡張基板に接続し、SWの入力やLED、LCD等への出力がありますが、
> 例えばSW入力に対する、LED点灯やLCD表示するまでの時間も長いのです。
> 弊社製の拡張基板に異常が有るのでは?と思い、ACアダプターから電源供給し、起動しましたが、
> 不具合症状は改善しませんでした。
⇒上記、御社製の拡張基板を外し、Armadillo-840単体で、出荷状態のイメージファイルで起動した
状態であるという認識で良いでしょうか。
⇒弊社拡張基板から取り外した状態で確認しました。よって、ソフトウェア(イメージファイル)の書換え等は
行っていません。
> 3.「2.ARMADILLO-840の起動時間が遅い」という方は、不具合動作が再現しなくなりました。
> ・[sched_delayed] sched: RT throttling activated
> ⇒起動ログにはありません
> ・load decoder firmware: failed
> ⇒load decoder firmware: acm_h264dec: H.264 Decoder of AV Codec Middleware
> acm_aacdec: AAC Decoder of AV Codec Middleware
> done と起動ログに表示されます。
> よって、AVコーデックミドルウェアがフラッシュメモリに書き込まれていないという原因では
> ないようです。
⇒上記、同一個体、同一ソフトウェアでの再現結果でしょうか。
⇒下記手順にて確認していました。この間、ソフトウェア(イメージファイル)の書換えは行っていません。
①弊社製の拡張基板にArmadillo-840が接続された状態・・・不具合症状有り
↓
②拡張基板からArmadillo-840を取り外す
↓
③Armadillo-840単体で確認・・・不具合症状あり ※ACアダプターからDC5Vを供給
↓
④弊社製の拡張基板に再度取り付ける・・・不具合症状なし
> 4.昨年も同じようなものが発生しており、
> ①御社から提供していただいたイメージファイルに書き換えても同様な問題が発生
> ②その後、弊社のイメージファイルに書き換えても同様な問題が発生
> 頻度は100%でした。
⇒もし、Armadillo-840単体で、全ソフトウェア(Hermit, Linuxの起動オプション, Linuxカーネル,
ユーザランド, config領域)が出荷状態でも問題が発生する場合は、該当個体に問題がある可能性
が高いです。
⇒下記手順にて確認をしました。同一個体にて確認。
<御社より提供されたイメージファイル>
・linux-a840-v1.21.bin.gz
・loader-armadillo840-nor-v3.11.0.bin
・romfs-a840-v1.14.img.gz
・squashfs-a800-firmware-v3.02.img
a.提供されたのイメージを書き込みました。(書込み時間34分50秒)
↓
b.rebootコマンド後の起動時間 4分08秒
↓
c.flatfsd -w コマンド後、電源OFF→ON後の起動時間 3分49秒 ※起動ログを添付(起動ログTest.txt)します。
↓
d.弊社のイメージを書き込みました。(書込み時間27分15秒)
↓
e.rebootコマンド後の起動時間 4分15秒
↓
f.flatfsd -w コマンド後、電源OFF→ON後の起動時間 3分45秒
以上、宜しくお願いします。
ファイル | ファイルの説明 |
---|---|
起動ログTest.txt |
at_mizo
2019年12月13日 11時50分
溝渕です。
> > 1.rebooted by watchdog timedout. は?
> :(省略)
> ⇒①何かしらの理由として考えられることを教えてください?
例えば次のような事が考えられます。
- 割り込みが頻繁に入っている
- 処理に長時間を要する割り込みハンドラが存在する
- 割り込み禁止区間に長時間滞在する
- デッドロックが発生している
> ②ボード自体が要因(実装部品の破壊、パターン断線、半田付け不良等)でしょうか?
> 或いはソフトウェア(イメージファイル)でしょうか?
> 仮に、ソフトウェア(イメージファイル)とすると、数的にもっと発生すると考えますが。。。
同感です。ソフトウェア要因で個体差が発生する可能性は低いかと思います。
> ③イメージファイルの書込みに失敗しているという事は、考えられますか?
考えられます。
フラッシュメモリへの書き込みを正常に実行できたかどうかは、Hermit-Atの
md5sumコマンドを利用して確認することができます。
[Armadilloに書き込んだイメージが正しく書かれているかを確認する(Hermit-At編)]
https://users.atmark-techno.com/blog/53/982
> > 2.起動時間が遅いと書きましたが、起動後の入力に対する出力の反応も遅いのですが、何が
> > 考えられますか?
> :(省略)
> ⇒①何かの処理とは? 考えられることを教えてください。
"1."の解答と同一です。
> ②ウォッチドックダイマーによるリセットが発生する事と関連性はありますか?
ウォッチドッグタイマーへのkickが実行できない状態では必ずリセットが実行
される為、関連性が無いとは言えません。
> > 4.昨年も同じようなものが発生しており、
> :(省略)
> ⇒下記手順にて確認をしました。同一個体にて確認。
> <御社より提供されたイメージファイル>
> ・linux-a840-v1.21.bin.gz
> ・loader-armadillo840-nor-v3.11.0.bin
> ・romfs-a840-v1.14.img.gz
> ・squashfs-a800-firmware-v3.02.img
>
> a.提供されたのイメージを書き込みました。(書込み時間34分50秒)
> ↓
> b.rebootコマンド後の起動時間 4分08秒
> ↓
> c.flatfsd -w コマンド後、電源OFF→ON後の起動時間 3分49秒 ※起動ログを添付(起動ログTest.txt)します。
> ↓
> d.弊社のイメージを書き込みました。(書込み時間27分15秒)
> ↓
> e.rebootコマンド後の起動時間 4分15秒
> ↓
> f.flatfsd -w コマンド後、電源OFF→ON後の起動時間 3分45秒
ご確認有難うございます。
Armadillo-840単体で、出荷イメージでも問題が発生しておりますので、以下
の手順でWebフォームからお問い合わせをお願い致します。
h_akiyama046
2019年12月13日 13時48分
at_mizo
2019年12月12日 20時25分
溝渕です。
> <質問事項>
> ・このログは、どのような意味ですか?
前者は、一定時間内にタスクが実行できなかったことを示しています。
後者は、AVコーデックミドルウェアのファームウェアが無いことを示しています。
> ・何が原因で、このような症状になりますか?
前者は、context switchが実行できない状態になっているのではないかと思います。
後者は、AVコーデックミドルウェアがフラッシュメモリに書き込まれていないのが原因です。
> ・対策方法、対策手段は?
後者は、AVコーデックミドルウェアをフラッシュメモリに掛き込むことによって解決できると思います。
前者は原因がわからないので、いくつか質問させてください。
- 出荷状態のイメージファイルでも同様の問題が発生しますか
- 個体差はありますか
- 再現頻度はどのくらいですか
出荷状態のイメージファイルは、以下より取得可能です。
https://users.atmark-techno.com/armadillo-840/software