I am developing a custom watchdog driver for the Beaglebone black SBC. There is an external entity connected to the BBB. It will reset the board if it wont receive a GPIO state change from the BBB within a certain time, that is settable through I2C. From what I have understood so far is that from the Linux software point of view, the /dev/watchdog device should be written to in order to refresh the watchdog peripheral, that's clear. Such thing could be done by the watchdog daemon: https://www.systutorials.com/docs/linux/man/8-watchdog/
The problem here is that it seems that the refresh interval is hard-coded to 60 seconds. For my application the interval is a lot shorter (about 5 seconds typically) and is settable (from 1 to 10 seconds). In this case I think I would not be able to use the watchdog daemon for the custom wdg driver.
Is there a way around this? Or is my take on this case not even correct?
Typically, if you want to use kernel watchdog framework, you can simply write some C code which is petting /dev/watchdog file with your own "watchdog frequency". There is no reason to use watchdog daemon if you have your own reasons.
And, the kernel watchdog framework is hooked into real hardware watchdog which is capable to detect lockup, and generate event based on expiration and if your hardware watchdog "timeout" or "expiration" interval can be tunnable, you can change the time and you can make not to fire for 60 seconds.
Normally, nobody is dealing with watchdog process which is provided by busybox or some other linux pkg. Most likely they are using it as it is. Also, as far as I remember, it is 1 seconds interval.
Related
I am using linux watchdog driver /dev/watchdog on a linux embedded system with busy box as user space tools. I want to trigger the watchdog from C/C++ code, which works fine for timeouts up to 60s:
watchdogFD = open( "/dev/watchdog", O_WRONLY );
int timeout = 60;
ioctl( watchdogFD, WDIOC_SETTIMEOUT, &timeout )
However for larger intervals the timeout is accepted, but the watchdog is triggered already after 60s.
The linux watchdog deamon offers a --force parameter to set timeouts larger than 60s (see https://linux.die.net/man/8/watchdog). However the busy box watchdog deamon does not offer this (see https://git.busybox.net/busybox/tree/miscutils/watchdog.c?id=1572f520ccfe9e45d4cb9b18bb7b728eb2bbb571).
Does anyone have a suggestion how to use the same --force option when controlling watchdog using ioctl? Thanks :)
It seems the busybox watchdog daemon you link to is very simple compared to the usual Linux one from here:
https://sourceforge.net/p/watchdog/code/ci/master/tree/
The --force option for the Linux daemon (above) is to override the sanity checks on the polling interval versus the hardware time-out used. It will not change any limits a specific hardware driver/timer has to offer.
Typically the choice of hardware time-out is in the 10-60 second range, depending on how long you can tolerate a major fault (like a kernel panic) persisting for. Then the watchdog daemon that feeds the timer has to poll at an interval that is at least a few seconds shorter so nothing timers out unexpectedly. Between polls it uses nanosleep() so gives up its CPU time, and so the system load for the daemon is proportional to the polling rate and the type of tests that are run.
Without any tests all you protect against is a major fault killing either the daemon or kernel, so usually you should be checking for something else that is essential for normal operations (e.g. a specific process being alive, files being updated, test script can be run, etc) to get the most benefit.
I'm looking for away to wake up a node programmatically, but I don't even know if it's possible.
The Context : I wrote a nodejs application that aim to interface z-wave modules thanks to node-openzwave-shared .
Every things works fine with lights but I recently got a PIR sensor that is sleeping directly when I start my nodejs application.
Does anyone know how to wake up my PIR sensor programmatically ? (I can wake it up by pressing a physical button but this solution does not satisfy me)
NB : What is the difference between a sleeping node and a awake node ? (I mean technicaly speaking) It'seems that sleeping node can't receive controller command but can anyone confirm this please ?
Sleeping devices can't be woken up pro grammatically, but most offer settings that can be changed to periodically wake up and provide updated sensor data as well as accepting commands.
I have a battery powered motion/light/temperature/humidity sensor that does that. It wakes on movement or provide a status update every 10 minutes.
Sleeping, on z-wave, just means non-responsive. From a device standpoint, it probably just means a powered down transmitter/receiver.
My question is related to knowledge on embedded Linux.
I just observed a strange reboot on my embedded project, which is very easy to reproduce.
When some condition is triggered, the system will like "freezing". I mean, its like encounter some infinite loop or be locked. Last for several seconds, system will quietly reboot. Not even core dump!!
I have no much clue about the cause. Generally will a lock or infinite loop can truly trigger Linux reboot? Or are there any things can freeze system and cause reboot with no core dump happens?
It is common on embedded systems to have a hardware watchdog; a timer implemented in hardware that resets the processor if it is allowed to expire.
Typically some software monitoring task continuously verifies the integrity of the system and restarts the hardware watchdog timer. If the monitoring task fails to run and the watchdog timer expires, the watchdog triggers a processor reset directly.
Your question is a bit hard to understand but yes, a "infinite loop" (the proper term is) in any application on any platform (including Linux) can crash a system. This happens obviously because an infinite loop can constantly take up memory and resources until there is none left. You mentioned you are doing embedded development (which can mean many different things) but usually means you are developing low-level applications built into Linux itself; these are more prone to crashing an OS than your average programming venture.
I'm working on an embedded linux platform.
When I do "echo "mem" > /sys/power/state", system will suspend.
I know that kernel and driver can know that suspend operation's coming. But would it be possible that a user space process or application can get the notification that the system will suspend? How?
For example, I have an application who writes 'A' continually into a buffer whose start address is given by a device driver. Would it be possible that this application be notified that the system will suspend so that it could replace all this buffer with 'B' so that when driver is resumed, all what driver sees are 'B'?
Thanks a lot.
Been searching for the same thing. But unfortunately, I didn't find any user space notification during suspend/resume. Applications are just refrigerated/frozen and they will never know they are suspended.
However, one possible approach would be to add a generic netlink message sending or uevent from any driver's suspend/resume function that you can modify. Still the application may never get enough time to process it before it is frozen and might lead to race conditions. Say it received the suspend message and got frozen before it could process it. And once resumed, it will be processing the suspend message.
IMO, it is better to handle the scenario in the driver. Leave the user space alone.
I'm not sure whether it's useful for you in particular, given the mention of "embedded", however systemd can notify you over DBus: https://www.freedesktop.org/wiki/Software/systemd/inhibit/
I want to write a program which notifies when the laptop battery level falls below a certain threshold level. I am using ubuntu 11.04 . Is there a way in which i can generate an interrupt without polling the battery. What system calls in linux are used to achieve this ?
There is no system call interface to ACPI in Linux... All of the I/O is done using /proc/acpi or /sys/class entries. Easiest implementation would be a polling software, and read the interface periodically (going to sleep if the threshold is not there yet) — this is because typically /proc and /sys files construct the desired information while handling the read(2).