^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) =============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) The Linux Watchdog driver API
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) =============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) Last reviewed: 10/05/2007
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) Copyright 2002 Christer Weingel <wingel@nano-system.com>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) Some parts of this document are copied verbatim from the sbc60xxwdt
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) driver which is (c) Copyright 2000 Jakob Oestergaard <jakob@ostenfeld.dk>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) This document describes the state of the Linux 2.4.18 kernel.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) Introduction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) ============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) A Watchdog Timer (WDT) is a hardware circuit that can reset the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) computer system in case of a software fault. You probably knew that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) already.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) Usually a userspace daemon will notify the kernel watchdog driver via the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) /dev/watchdog special device file that userspace is still alive, at
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) regular intervals. When such a notification occurs, the driver will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) usually tell the hardware watchdog that everything is in order, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) that the watchdog should wait for yet another little while to reset
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) the system. If userspace fails (RAM error, kernel bug, whatever), the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) notifications cease to occur, and the hardware watchdog will reset the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) system (causing a reboot) after the timeout occurs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) The Linux watchdog API is a rather ad-hoc construction and different
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) drivers implement different, and sometimes incompatible, parts of it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) This file is an attempt to document the existing usage and allow
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) future driver writers to use it as a reference.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) The simplest API
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) ================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) All drivers support the basic mode of operation, where the watchdog
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) activates as soon as /dev/watchdog is opened and will reboot unless
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) the watchdog is pinged within a certain time, this time is called the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) timeout or margin. The simplest way to ping the watchdog is to write
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) some data to the device. So a very simple watchdog daemon would look
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) like this source file: see samples/watchdog/watchdog-simple.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) A more advanced driver could for example check that a HTTP server is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) still responding before doing the write call to ping the watchdog.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) When the device is closed, the watchdog is disabled, unless the "Magic
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) Close" feature is supported (see below). This is not always such a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) good idea, since if there is a bug in the watchdog daemon and it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) crashes the system will not reboot. Because of this, some of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) drivers support the configuration option "Disable watchdog shutdown on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) close", CONFIG_WATCHDOG_NOWAYOUT. If it is set to Y when compiling
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) the kernel, there is no way of disabling the watchdog once it has been
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) started. So, if the watchdog daemon crashes, the system will reboot
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) after the timeout has passed. Watchdog devices also usually support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) the nowayout module parameter so that this option can be controlled at
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) runtime.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) Magic Close feature
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) ===================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) If a driver supports "Magic Close", the driver will not disable the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) watchdog unless a specific magic character 'V' has been sent to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) /dev/watchdog just before closing the file. If the userspace daemon
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) closes the file without sending this special character, the driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) will assume that the daemon (and userspace in general) died, and will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) stop pinging the watchdog without disabling it first. This will then
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) cause a reboot if the watchdog is not re-opened in sufficient time.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) The ioctl API
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) =============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) All conforming drivers also support an ioctl API.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) Pinging the watchdog using an ioctl:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) All drivers that have an ioctl interface support at least one ioctl,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) KEEPALIVE. This ioctl does exactly the same thing as a write to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) watchdog device, so the main loop in the above program could be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) replaced with::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) while (1) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) ioctl(fd, WDIOC_KEEPALIVE, 0);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) sleep(10);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) the argument to the ioctl is ignored.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) Setting and getting the timeout
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) ===============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) For some drivers it is possible to modify the watchdog timeout on the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) fly with the SETTIMEOUT ioctl, those drivers have the WDIOF_SETTIMEOUT
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) flag set in their option field. The argument is an integer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) representing the timeout in seconds. The driver returns the real
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) timeout used in the same variable, and this timeout might differ from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) the requested one due to limitation of the hardware::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) int timeout = 45;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) ioctl(fd, WDIOC_SETTIMEOUT, &timeout);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) printf("The timeout was set to %d seconds\n", timeout);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) This example might actually print "The timeout was set to 60 seconds"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) if the device has a granularity of minutes for its timeout.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) Starting with the Linux 2.4.18 kernel, it is possible to query the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) current timeout using the GETTIMEOUT ioctl::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) ioctl(fd, WDIOC_GETTIMEOUT, &timeout);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) printf("The timeout was is %d seconds\n", timeout);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) Pretimeouts
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) ===========
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) Some watchdog timers can be set to have a trigger go off before the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) actual time they will reset the system. This can be done with an NMI,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) interrupt, or other mechanism. This allows Linux to record useful
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) information (like panic information and kernel coredumps) before it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) resets::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) pretimeout = 10;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) ioctl(fd, WDIOC_SETPRETIMEOUT, &pretimeout);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) Note that the pretimeout is the number of seconds before the time
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) when the timeout will go off. It is not the number of seconds until
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) the pretimeout. So, for instance, if you set the timeout to 60 seconds
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) and the pretimeout to 10 seconds, the pretimeout will go off in 50
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) seconds. Setting a pretimeout to zero disables it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) There is also a get function for getting the pretimeout::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) ioctl(fd, WDIOC_GETPRETIMEOUT, &timeout);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) printf("The pretimeout was is %d seconds\n", timeout);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) Not all watchdog drivers will support a pretimeout.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) Get the number of seconds before reboot
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) =======================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) Some watchdog drivers have the ability to report the remaining time
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) before the system will reboot. The WDIOC_GETTIMELEFT is the ioctl
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) that returns the number of seconds before reboot::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) ioctl(fd, WDIOC_GETTIMELEFT, &timeleft);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) printf("The timeout was is %d seconds\n", timeleft);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) Environmental monitoring
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) ========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) All watchdog drivers are required return more information about the system,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) some do temperature, fan and power level monitoring, some can tell you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) the reason for the last reboot of the system. The GETSUPPORT ioctl is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) available to ask what the device can do::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) struct watchdog_info ident;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) ioctl(fd, WDIOC_GETSUPPORT, &ident);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) the fields returned in the ident struct are:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) ================ =============================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) identity a string identifying the watchdog driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) firmware_version the firmware version of the card if available
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) options a flags describing what the device supports
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) ================ =============================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) the options field can have the following bits set, and describes what
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) kind of information that the GET_STATUS and GET_BOOT_STATUS ioctls can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) return.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) ================ =========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) WDIOF_OVERHEAT Reset due to CPU overheat
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) ================ =========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) The machine was last rebooted by the watchdog because the thermal limit was
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) exceeded:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) ============== ==========
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) WDIOF_FANFAULT Fan failed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) ============== ==========
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) A system fan monitored by the watchdog card has failed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) ============= ================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) WDIOF_EXTERN1 External relay 1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) ============= ================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) External monitoring relay/source 1 was triggered. Controllers intended for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) real world applications include external monitoring pins that will trigger
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) a reset.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) ============= ================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) WDIOF_EXTERN2 External relay 2
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) ============= ================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) External monitoring relay/source 2 was triggered
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) ================ =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) WDIOF_POWERUNDER Power bad/power fault
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) ================ =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) The machine is showing an undervoltage status
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) =============== =============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) WDIOF_CARDRESET Card previously reset the CPU
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) =============== =============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) The last reboot was caused by the watchdog card
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) ================ =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) WDIOF_POWEROVER Power over voltage
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) ================ =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) The machine is showing an overvoltage status. Note that if one level is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) under and one over both bits will be set - this may seem odd but makes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) sense.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) =================== =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) WDIOF_KEEPALIVEPING Keep alive ping reply
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) =================== =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) The watchdog saw a keepalive ping since it was last queried.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) ================ =======================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) WDIOF_SETTIMEOUT Can set/get the timeout
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) ================ =======================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) The watchdog can do pretimeouts.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) ================ ================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) WDIOF_PRETIMEOUT Pretimeout (in seconds), get/set
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) ================ ================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) For those drivers that return any bits set in the option field, the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) GETSTATUS and GETBOOTSTATUS ioctls can be used to ask for the current
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) status, and the status at the last reboot, respectively::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) int flags;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) ioctl(fd, WDIOC_GETSTATUS, &flags);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244) or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) ioctl(fd, WDIOC_GETBOOTSTATUS, &flags);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248) Note that not all devices support these two calls, and some only
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) support the GETBOOTSTATUS call.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251) Some drivers can measure the temperature using the GETTEMP ioctl. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252) returned value is the temperature in degrees fahrenheit::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254) int temperature;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255) ioctl(fd, WDIOC_GETTEMP, &temperature);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257) Finally the SETOPTIONS ioctl can be used to control some aspects of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258) the cards operation::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260) int options = 0;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261) ioctl(fd, WDIOC_SETOPTIONS, &options);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263) The following options are available:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265) ================= ================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266) WDIOS_DISABLECARD Turn off the watchdog timer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267) WDIOS_ENABLECARD Turn on the watchdog timer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268) WDIOS_TEMPPANIC Kernel panic on temperature trip
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269) ================= ================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 271) [FIXME -- better explanations]
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags