谁在刷新Linux中的硬件看门狗？

发布于 2024-08-17 02:19:32 字数 1294 浏览 8 评论 0原文

我有一个运行 2.6 内核的处理器 AT91SAM9G20。看门狗在引导级别启用并配置为 16 秒。看门狗模式寄存器只能配置一次。当代码挂在引导程序、引导加载程序或内核中时，主板将重新启动。但是，一旦内核启动，即使看门狗在任何应用程序中都没有刷新，主板也不会在 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 中提供的看门狗进行软锁定

原文

I have a processor AT91SAM9G20 running a 2.6 kernel. Watchdog is enabled at bootstrap level and configured for 16 seconds. Watchdog mode register can be configured only once.
When code hangs either in bootstrap, bootloader or kernel, the board reboots. But once kernel comes up even though watchdog is not refreshed in any of the applications, the board is not being reset after 16 seconds, but 15 minutes.

Who is refreshing the watchdog?

In our case, the watchdog should be influenced by applications, so that the board can reset if our application hangs.

These are the running processes:

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

We are using the watchdog for soft lockups available in kernel-2.6.25-ts.at91sam9g20/kernel/softlockup.c

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

同展鸳鸯锦 2024-08-24 02:19:32

如果您在内核中启用了看门狗驱动程序，则看门狗驱动程序会设置一个内核计时器，负责重置看门狗。对应的代码为 linux/drivers/watchdog/at91sam9_wdt.c 。所以它的工作原理是这样的：

如果没有应用程序打开 /dev/watchdog 文件，那么内核会负责重置看门狗。由于它是一个定时器，因此它不会出现为专用的内核线程，而是由软IRQ线程处理。现在，如果应用程序打开此文件，它就会对看门狗负责，并且可以通过写入该文件来重置它，如理查德帖子中链接的文档所述。

你的内核中是否配置了看门狗驱动程序？
如果没有，您应该对其进行配置，并查看重置是否仍然发生。如果仍然发生，则您的重置可能来自其他地方。

如果您的内核太旧而没有适当的看门狗驱动程序（2.6.25 中不存在），您应该从 2.6.28 向后移植它。或者您可以尝试禁用引导加载程序中的看门狗，然后查看重置是否仍然发生。

回复收藏 0 原文

心碎的声音 2024-08-24 02:19:32

2016 年 7 月将 4.7 内核中的 3fbfe92647（watchdog：更改 watchdog_need_worker 逻辑）提交为 < code>watchdog_dev.c 为所有看门狗定时器驱动程序启用了与 shodanex 的答案相同的行为。除了这个线程和源代码之外，这似乎没有在任何地方记录。

/*
* 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));

In July 2016 commit 3fbfe92647 (watchdog: change watchdog_need_worker logic) in the 4.7 kernel to watchdog_dev.c enabled the same behavior as shodanex's answer for all watchdog timer drivers. This doesn't seem to be documented anywhere other than this thread and the source code.

/*
* 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));

回复收藏 0 原文