Lines Matching refs:the
8 Some parts of this document are copied verbatim from the sbc60xxwdt
11 This document describes the state of the Linux 2.4.18 kernel.
15 A Watchdog Timer (WDT) is a hardware circuit that can reset the
19 Usually a userspace daemon will notify the kernel watchdog driver via the
21 regular intervals. When such a notification occurs, the driver will
22 usually tell the hardware watchdog that everything is in order, and
23 that the watchdog should wait for yet another little while to reset
24 the system. If userspace fails (RAM error, kernel bug, whatever), the
25 notifications cease to occur, and the hardware watchdog will reset the
26 system (causing a reboot) after the timeout occurs.
30 This file is an attempt to document the existing usage and allow
35 All drivers support the basic mode of operation, where the watchdog
37 the watchdog is pinged within a certain time, this time is called the
38 timeout or margin. The simplest way to ping the watchdog is to write
39 some data to the device. So a very simple watchdog daemon would look
43 still responding before doing the write call to ping the watchdog.
45 When the device is closed, the watchdog is disabled, unless the "Magic
47 good idea, since if there is a bug in the watchdog daemon and it
48 crashes the system will not reboot. Because of this, some of the
49 drivers support the configuration option "Disable watchdog shutdown on
51 the kernel, there is no way of disabling the watchdog once it has been
52 started. So, if the watchdog daemon crashes, the system will reboot
53 after the timeout has passed. Watchdog devices also usually support
54 the nowayout module parameter so that this option can be controlled at
59 If a driver supports "Magic Close", the driver will not disable the
61 /dev/watchdog just before closing the file. If the userspace daemon
62 closes the file without sending this special character, the driver
63 will assume that the daemon (and userspace in general) died, and will
64 stop pinging the watchdog without disabling it first. This will then
65 cause a reboot if the watchdog is not re-opened in sufficient time.
71 Pinging the watchdog using an ioctl:
74 KEEPALIVE. This ioctl does exactly the same thing as a write to the
75 watchdog device, so the main loop in the above program could be
83 the argument to the ioctl is ignored.
85 Setting and getting the timeout:
87 For some drivers it is possible to modify the watchdog timeout on the
88 fly with the SETTIMEOUT ioctl, those drivers have the WDIOF_SETTIMEOUT
90 representing the timeout in seconds. The driver returns the real
91 timeout used in the same variable, and this timeout might differ from
92 the requested one due to limitation of the hardware.
99 if the device has a granularity of minutes for its timeout.
101 Starting with the Linux 2.4.18 kernel, it is possible to query the
102 current timeout using the GETTIMEOUT ioctl.
109 Some watchdog timers can be set to have a trigger go off before the
110 actual time they will reset the system. This can be done with an NMI,
118 Note that the pretimeout is the number of seconds before the time
119 when the timeout will go off. It is not the number of seconds until
120 the pretimeout. So, for instance, if you set the timeout to 60 seconds
121 and the pretimeout to 10 seconds, the pretimeout will go off in 50
124 There is also a get function for getting the pretimeout:
131 Get the number of seconds before reboot:
133 Some watchdog drivers have the ability to report the remaining time
134 before the system will reboot. The WDIOC_GETTIMELEFT is the ioctl
135 that returns the number of seconds before reboot.
142 All watchdog drivers are required return more information about the system,
144 the reason for the last reboot of the system. The GETSUPPORT ioctl is
145 available to ask what the device can do:
150 the fields returned in the ident struct are:
152 identity a string identifying the watchdog driver
153 firmware_version the firmware version of the card if available
154 options a flags describing what the device supports
156 the options field can have the following bits set, and describes what
157 kind of information that the GET_STATUS and GET_BOOT_STATUS ioctls can
162 The machine was last rebooted by the watchdog because the thermal limit was
167 A system fan monitored by the watchdog card has failed
183 WDIOF_CARDRESET Card previously reset the CPU
185 The last reboot was caused by the watchdog card
197 WDIOF_SETTIMEOUT Can set/get the timeout
204 For those drivers that return any bits set in the option field, the
205 GETSTATUS and GETBOOTSTATUS ioctls can be used to ask for the current
206 status, and the status at the last reboot, respectively.
216 support the GETBOOTSTATUS call.
218 Some drivers can measure the temperature using the GETTEMP ioctl. The
219 returned value is the temperature in degrees fahrenheit.
224 Finally the SETOPTIONS ioctl can be used to control some aspects of
225 the cards operation.
232 WDIOS_DISABLECARD Turn off the watchdog timer
233 WDIOS_ENABLECARD Turn on the watchdog timer