18

2.6 カーネルを実行するプロセッサ AT91SAM9G20 を使用しています。ウォッチドッグはブートストラップ レベルで有効になり、16 秒間設定されます。ウォッチドッグ モード レジスタは 1 回だけ設定できます。コードがブートストラップ、ブートローダー、またはカーネルでハングすると、ボードが再起動します。ただし、どのアプリケーションでもウォッチドッグが更新されていなくてもカーネルが起動すると、ボードは 16 秒後ではなく 15 分後にリセットされます。

ウォッチドッグを更新しているのは誰ですか?

この場合、アプリケーションがハングした場合にボードをリセットできるように、ウォッチドッグはアプリケーションの影響を受ける必要があります。

実行中のプロセスは次のとおりです。

1 root     init
2 root     [kthreadd]
3 root     [ksoftirqd/0]
4 root     [watchdog/0]
5 root     [events/0]
6 root     [khelper]
63 root     [kblockd/0]
72 root     [ksuspend_usbd]
78 root     [khubd]
85 root     [kmmcd]
107 root     [pdflush]
108 root     [pdflush]
109 root     [kswapd0]
110 root     [aio/0]
740 root     [mtdblockd]
828 root     [rpciod/0]
982 root     [jffs2_gcd_mtd10]
1003 root     /sbin/udevd -d
1145 daemon   portmap
1158 dbus     dbus-daemon --system
1178 root     /usr/sbin/ifplugd -i eth0 -fwI -u0 -d5 -l -q
1190 root     /usr/sbin/ifplugd -i eth1 -fwI -u0 -d5 -l -q
1221 default  avahi-daemon: running [SP14.local]
1226 root     /usr/sbin/dropbear
1246 root     /root/bin/host_app
1254 root     /root/bin/mini_httpd -c *.cgi -d /root/bin -u root -E /root/bin/
1256 root     -sh
1257 root     /sbin/syslogd -n -m 0
1258 root     /sbin/klogd -n
1259 root     /usr/bin/tail -f /var/log/messages
1265 root     ps -e

kernel-2.6.25-ts.at91sam9g20/kernel/softlockup.c で利用可能なソフト ロックアップのウォッチドッグを使用しています。

4

5 に答える 5

18

カーネルでウォッチドッグ ドライバーを有効にした場合、ウォッチドッグ ドライバーは、ウォッチドッグのリセットを担当するカーネル タイマーをセットアップします。対応するコードはlinux/drivers/watchdog/at91sam9_wdt.cです。したがって、次のように機能します。

ファイルを開くアプリケーションがない場合は/dev/watchdog、カーネルがウォッチドッグのリセットを処理します。これはタイマーであるため、専用のカーネル スレッドとして表示されませんが、ソフト IRQ スレッドによって処理されます。これで、アプリケーションがこのファイルを開くと、ウォッチドッグの責任を負うようになり、Richard の投稿にリンクされているドキュメントに記載されているように、ファイルに書き込むことでリセットできます。

ウォッチドッグ ドライバーはカーネルで構成されていますか? そうでない場合は、構成して、リセットが引き続き発生するかどうかを確認する必要があります。それでも発生する場合は、リセットが別の場所から発生している可能性があります。

カーネルが古すぎて適切なウォッチドッグ ドライバーがない場合 (2.6.25 には存在しない)、2.6.28 からバックポートする必要があります。または、ブートローダーでウォッチドッグを無効にして、リセットが引き続き発生するかどうかを確認することもできます。

于 2010-01-07T13:48:53.167 に答える
7

2016 年 7 月に 4.7 カーネルで 3fbfe92647 (watchdog: change watchdog_need_worker logic) をコミットして、すべてのウォッチドッグ タイマー ドライバーに対してshodanex の回答watchdog_dev.cと同じ動作を有効にしました。これは、このスレッドとソース コード以外には文書化されていないようです。

/*
* A worker to generate heartbeat requests is needed if all of the
* following conditions are true.
* - Userspace activated the watchdog.
* - The driver provided a value for the maximum hardware timeout, and
*   thus is aware that the framework supports generating heartbeat
*   requests.
* - Userspace requests a longer timeout than the hardware can handle.
*
* Alternatively, if userspace has not opened the watchdog
* device, we take care of feeding the watchdog if it is
* running.
*/

return (hm && watchdog_active(wdd) && t > hm) ||
       (t && !watchdog_active(wdd) && watchdog_hw_running(wdd));
于 2017-03-03T21:55:47.237 に答える
6

これはあなたにヒントを与えるかもしれません：http ：//www.mjmwired.net/kernel/Documentation/watchdog/watchdog-api.txt

ユーザースペースデーモンがウォッチドッグを処理することは完全に理にかなっています。おそらくデフォルトで15分のタイムアウトになります。

于 2010-01-07T13:19:10.520 に答える
2

AT91SAM9263 の WDT に関して同様の問題がありました。WDT_MR (アドレス: 0xFFFFFD44) レジスタのビット 29 WDIDLEHLT に問題がありました。このビットは 1 に設定されていますが、アプリケーションのニーズでは 0 にする必要があります。

データシートのドキュメントからのビットの説明:

• WDIDLEHLT: ウォッチドッグ アイドル停止

  1. 0: システムがアイドル モードのときにウォッチドッグが実行されます。
  2. 1: システムがアイドル状態の場合、ウォッチドッグは停止します。

これは、カーネルがアイドル状態の場合、WDT カウンターがインクリメントしないことを意味します。したがって、リセットが発生するまでに 15 以上の遅延が発生します。

「dd if=/dev/zero of=/dev/null」を試すと、カーネルがアイドル状態に入るのを防ぐことができ、16 秒 (または WDT_MR レジスタで設定した期間) でリセットされるはずです。

したがって、解決策は、u-boot コードまたは WDT_MR レジスタを設定するその他のコードを更新することです。このレジスタは一度だけ書き込みます...

于 2015-07-27T11:29:07.147 に答える
0

カーネルがウォッチドッグ タイマーを更新しているのではないでしょうか? ウォッチドッグは、単一のアプリケーションだけでなく、システム全体がハングした場合にボードをリセットするように設計されています。

于 2010-01-07T13:14:05.560 に答える