About internal heartbeat timer
Hi
I have a doubt about the use of internal timer to reset the wdt when the watchdog device was closed from userspace and it doesn't support stopping the wdt. I think, in my modest opinion, that if the watchdog device was closed at userspace it means that something is wrong at userspace and the system needs to be rebooted.
I think that the internal timer can be useful in the following scenario:
If an user reboot the system, then the internal timer must ensure that the watchdog didn't reset the system during the reboot process and it send ticks to the wdt until the user/clean reboot process get finished. Maybe a reboot notifier can be used to detect when the user reboot the system manually.
thanks and feel free to comment about this
Alejandro
Participe en Universidad 2012, del 13 al 17 de febrero de 2012. Habana, Cuba: http://www.congresouniversidad.cu
Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu
Participe en el Segundo Congreso Medio Ambiente Construido y Desarrollo Sustentable (MACDES 2011) del 6 al 9 de diciembre de 2011, Hotel Nacional, Habana, Cuba: http://macdes.cujae.edu.cu
Hi Alejandro,
Quoted 6 lines
I have a doubt about the use of internal timer to reset the wdt when the watchdog device was closed from userspace and it doesn't support stopping the wdt.
I think, in my modest opinion, that if the watchdog device was closed at userspace it means that something is wrong at userspace and the system needs to be rebooted.
No. the reason why magic_close was introduced in the past is because there was a need to be able to tell the driver that it could correctly stop. For instance for maintenance work, where the watchdog device should NOT reboot the system during the maintenance.
So the reason why we sent that magic char is because we want to tell the driver that a watchdog daemon will stop working. In that case you do need that timer.
Quoted 6 lines
I think that the internal timer can be useful in the following scenario:
If an user reboot the system, then the internal timer must ensure that the watchdog didn't reset the system during the reboot process and it send ticks to the wdt until the user/clean reboot process get finished. Maybe a reboot notifier can be used to detect when the user reboot the system manually.
If a system is rebooted then the watchdog device is also resetted. So until you start the watchdog, it will not be activated...
Kind regards,
Wim.
Hi Wim
Quoted 6 lines
Quoted 6 lines
I have a doubt about the use of internal timer to reset the wdt when the watchdog device was closed from userspace and it doesn't support stopping the wdt.
I think, in my modest opinion, that if the watchdog device was closed at userspace it means that something is wrong at userspace and the system needs to be rebooted.
Quoted 7 lines
No. the reason why
magic_closewas introduced in the past is because there was a need to be able to tell the driver that it could correctly stop. For instance for maintenance work, where the watchdog device should NOT reboot the system during the maintenance.
So the reason why we sent that magic char is because we want to tell the driver that a watchdog daemon will stop working. In that case you do need that timer.
I see...but as I can see in the Generic Watchdog Framework patch series, the timer only needs that the bit WDOG_ACTIVE active to keep resetting the wdt....please take a look at my comment about patch number 7
Quoted 8 lines
Quoted 6 lines
I think that the internal timer can be useful in the following scenario:
If an user reboot the system, then the internal timer must ensure that the watchdog didn't reset the system during the reboot process and it send ticks to the wdt until the user/clean reboot process get finished. Maybe a reboot notifier can be used to detect when the user reboot the system manually.If a system is rebooted then the watchdog device is also resetted. So until you start the watchdog, it will not be activated...
Yes, but I'm thinking in the following case: if the system was restarting (clean reboot) and it take more than the watchdog timeout or the timeleft was very small to do a clean reboot....then the wdt reset the system and maybe it can be corrupt it. Maybe this case is weird and uncommon, but it has a chance to occur.
Best regards
Alejandro
Participe en Universidad 2012, del 13 al 17 de febrero de 2012. Habana, Cuba: http://www.congresouniversidad.cu
Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu
Participe en el Segundo Congreso Medio Ambiente Construido y Desarrollo Sustentable (MACDES 2011) del 6 al 9 de diciembre de 2011, Hotel Nacional, Habana, Cuba: http://macdes.cujae.edu.cu
Hi Alejandro,
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
I think that the internal timer can be useful in the following scenario:
If an user reboot the system, then the internal timer must ensure that the watchdog didn't reset the system during the reboot process and it send ticks to the wdt until the user/clean reboot process get finished. Maybe a reboot notifier can be used to detect when the user reboot the system manually.
Quoted 8 lines
Quoted 2 lines
If a system is rebooted then the watchdog device is also resetted. So until you start the watchdog, it will not be activated...
Yes, but I'm thinking in the following case: if the system was restarting (clean reboot) and it take more than the watchdog timeout or the timeleft was very small to do a clean reboot....then the wdt reset the system and maybe it can be corrupt it.
Maybe this case is weird and uncommon, but it has a chance to occur.
Don't forget that most watchdog drivers allready use a reboot_notifier or a platform shutdown method, to stop the watchdog before rebooting. And secondly, when watchdog devices are initialised the default behaviour is to stop the watchdog during initialisation (but it is allowed to have an option to manually change this behaviour so that the user can choose).
Kind regards,
Wim.