【问题标题】:Watchdog timer > 60s in linux embeddedlinux嵌入式看门狗定时器> 60s
【发布时间】:2017-11-02 14:16:35
【问题描述】:

我在一个 linux 嵌入式系统上使用 linux 看门狗驱动程序 /dev/watchdog 作为用户空间工具。我想从 C/C++ 代码触发看门狗,它适用于最长 60 秒的超时:

watchdogFD = open( "/dev/watchdog", O_WRONLY );
int timeout = 60;
ioctl( watchdogFD, WDIOC_SETTIMEOUT, &timeout )

但是对于较大的间隔,超时被接受,但看门狗已经在 60 秒后被触发。

Linux 看门狗守护程序提供了一个 --force 参数来设置大于 60 秒的超时(请参阅https://linux.die.net/man/8/watchdog)。但是,busy box 看门狗守护进程不提供此功能(请参阅https://git.busybox.net/busybox/tree/miscutils/watchdog.c?id=1572f520ccfe9e45d4cb9b18bb7b728eb2bbb571)。

有没有人建议在使用 ioctl 控制看门狗时如何使用相同的 --force 选项?谢谢:)

【问题讨论】:

  • 您系统上的硬件看门狗定时器完全有可能不支持超过 60 秒的超时。
  • @larsks 您是在暗示,如果提供硬件支持,值 > 60s 的 ioctl( WDIOC_SETTIMEOUT) 实际上应该可以工作吗?
  • 不,相反:看门狗定时器的长度可能存在硬件限制。我不知道是不是这样。我只是在猜测。
  • 如果物理硬件不支持它,那么驱动程序可以更频繁地踢看门狗(没有用户空间踢)以延长超时。我不认为你想要一个中断不能工作 60 秒的系统,所以驱动程序扩展可以吗?我认为您需要在通话后打印“超时”。为什么要传递引用而不是值?有人改了吗?还尝试改进看门狗进程和/或非关键 GUI 或任何占用 60 秒的东西(这非常疯狂)。这可能是一些非忙箱守护进程所做的。
  • @artlessnoise 驱动程序扩展对我来说没问题,我在哪里可以找到这样的扩展? 'timeout' 变量作为参考传递,因为 ioctl 调用将设置真正使用的超时,以防驱动程序需要调整值(所以我的硬件超时设置为 60,而之前它较大)。

标签: linux arm embedded-linux busybox watchdog


【解决方案1】:

看起来你链接到的busybox看门狗守护进程与这里的普通Linux相比非常简单:

https://sourceforge.net/p/watchdog/code/ci/master/tree/

Linux 守护程序(上图)的 --force 选项是覆盖轮询间隔与使用的硬件超时的健全性检查。它不会改变特定硬件驱动程序/计时器必须提供的任何限制。

硬件超时的选择通常在 10 到 60 秒的范围内,这取决于您可以容忍主要故障(如内核崩溃)持续多长时间。然后,为计时器提供数据的看门狗守护程序必须以至少短几秒的时间间隔进行轮询,这样就不会发生意外的计时器超时。在轮询之间它使用 nanosleep() 从而放弃它的 CPU 时间,因此守护进程的系统负载与轮询率和运行的测试类型成正比。

在没有任何测试的情况下,您所要防止的只是杀死守护程序或内核的重大故障,因此通常您应该检查对正常操作至关重要的其他内容(例如,特定进程处于活动状态、文件正在更新、测试脚本可以运行等)以获得最大收益。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-04-09
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多