Discussion:
regarding procd and manually controlling hardware watchdog
(too old to reply)
Valent Turkovic
2018-03-16 18:48:47 UTC
Permalink
Hi,
i just finished writing a detailed blog post regarding how to use
hardware watchdog and how to manually take control over from procd:

http://kernelreloaded.com/manually-controlling-openwrt-hardware-watchdog/

Over the years there were few questions regarding this and first there
was no way to do it (missing magicclose feature) and documentation was
lacking even after it was implemented.

Hopefully this helps some people.

If you have any suggestions or comments regarding this blog post feel
free to write here or contact me directly.

Cheers,
Valent.
John Crispin
2018-03-16 19:14:56 UTC
Permalink
Post by Valent Turkovic
Hi,
i just finished writing a detailed blog post regarding how to use
http://kernelreloaded.com/manually-controlling-openwrt-hardware-watchdog/
Over the years there were few questions regarding this and first there
was no way to do it (missing magicclose feature) and documentation was
lacking even after it was implemented.
Hopefully this helps some people.
If you have any suggestions or comments regarding this blog post feel
free to write here or contact me directly.
Cheers,
Valent.
_______________________________________________
openwrt-devel mailing list
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Hey,

just coz I am curious, why would you want to manually control the WDT ?

    John
Valent Turkovic
2018-03-17 18:08:31 UTC
Permalink
Using internal hardware watchdog would mean that we could remove
external hardware watchdog that we currently have on some customers
products.
I'm working on embedded products based upon OpenWrt and mips hardware
that use usb lte modems, openvpn, spi flash memory (actually now
replaced with onboard emmc drive)...

These are very complex devices when compared to "standard" embedded
devices, and with complexity you get more issues. We have software
watchdog scripts that try to fix things automatically, and last resort
is to reboot the device.

Have you even seen that device doesn't reboot after giving it reboot
command? Well, I have seen it. It is rare, but still it happens some
times. So if reboot command fails for three times in a row then we
stop tickling external watchdog which cuts power for 1 second.

Now I would tickle internal watchdog in same way. Other way would be
to just issue ubus command to stop tickling watchdog but when system
(very rarely) get into this weird state I'm not sure if ubus commands
would work.

Because our devices are spread all around Germany it is better to have
a really good and redundant watchdog then to drive somewhere for few
hundred kilometres.

Hope this satisfies your curiosity, John.

Cheers,
Valent.
Post by John Crispin
Post by Valent Turkovic
Hi,
i just finished writing a detailed blog post regarding how to use
http://kernelreloaded.com/manually-controlling-openwrt-hardware-watchdog/
Over the years there were few questions regarding this and first there
was no way to do it (missing magicclose feature) and documentation was
lacking even after it was implemented.
Hopefully this helps some people.
If you have any suggestions or comments regarding this blog post feel
free to write here or contact me directly.
Cheers,
Valent.
_______________________________________________
openwrt-devel mailing list
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Hey,
just coz I am curious, why would you want to manually control the WDT ?
John
Karl Palsson
2018-03-19 10:17:38 UTC
Permalink
Post by Valent Turkovic
Using internal hardware watchdog would mean that we could
remove external hardware watchdog that we currently have on
some customers products. I'm working on embedded products based
upon OpenWrt and mips hardware that use usb lte modems,
openvpn, spi flash memory (actually now replaced with onboard
emmc drive)...
These are very complex devices when compared to "standard"
embedded devices, and with complexity you get more issues. We
have software watchdog scripts that try to fix things
automatically, and last resort is to reboot the device.
Have you even seen that device doesn't reboot after giving it
reboot command? Well, I have seen it. It is rare, but still it
happens some times. So if reboot command fails for three times
in a row then we stop tickling external watchdog which cuts
power for 1 second.
yes! see https://github.com/openwrt/openwrt/pull/747
and
https://dev.openwrt.org/ticket/12121
and
https://dev.openwrt.org/ticket/17839#comment:51
and also, for what's likely the same issue...
errata ERR007117 for IMX6DQCE

though, honestly, these are cases where the _watchdog_ is the
problem. You _need_ to do a "nice" reboot, watchdog reboots make
it worse.
Post by Valent Turkovic
Now I would tickle internal watchdog in same way. Other way
would be to just issue ubus command to stop tickling watchdog
but when system (very rarely) get into this weird state I'm not
sure if ubus commands would work.
Because our devices are spread all around Germany it is better
to have a really good and redundant watchdog then to drive
somewhere for few hundred kilometres.
Hope this satisfies your curiosity, John.
Cheers,
Valent.
On Fri, Mar 16, 2018 at 8:14 PM, John Crispin
Post by John Crispin
Post by Valent Turkovic
Hi,
i just finished writing a detailed blog post regarding how to use
http://kernelreloaded.com/manually-controlling-openwrt-hardware-watchdog/
Over the years there were few questions regarding this and first there
was no way to do it (missing magicclose feature) and documentation was
lacking even after it was implemented.
Hopefully this helps some people.
If you have any suggestions or comments regarding this blog post feel
free to write here or contact me directly.
Cheers,
Valent.
_______________________________________________
openwrt-devel mailing list
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Hey,
just coz I am curious, why would you want to manually control the WDT ?
John
_______________________________________________
openwrt-devel mailing list
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Loading...