Hello everyone. Currently, the watchdog interface only has "stop watchdog on
restart" but lacks a "start watchdog on restart" one. Is there a way to achieve
such functionality?
I'd like to know why "stop watchdog on restart" wasn't implemented via ioctl
interface? It would be more convenient from user perspective and you can
control that behavior whenever you want from application layer.
I have some thoughts on this problem that solve the aforementioned
issue with "start watchdog on restart" but I don't think that my solution is
correct.
Looking forward for your feedback.
Thanks.
Le 02/09/2020 à 15:02, Ivan Mikhaylov a écrit :
> Hello everyone. Currently, the watchdog interface only has "stop watchdog on
> restart" but lacks a "start watchdog on restart" one. Is there a way to achieve
> such functionality?
>
> I'd like to know why "stop watchdog on restart" wasn't implemented via ioctl
> interface? It would be more convenient from user perspective and you can
> control that behavior whenever you want from application layer.
>
> I have some thoughts on this problem that solve the aforementioned
> issue with "start watchdog on restart" but I don't think that my solution is
> correct.
>
I don't understand why a "start watchdog on restart" would be needed.
Isn't it the default expected behaviour for a watchdog ?
"stop watchdog on restart" is there to keep things under control during
a wanted machine reboot/restart, while still having the watchdog do its
job on an unexpected restart.
What would be the advantage of an ioctl() compared to the existing way ?
Christophe
On 9/2/20 6:02 AM, Ivan Mikhaylov wrote:
> Hello everyone. Currently, the watchdog interface only has "stop watchdog on
> restart" but lacks a "start watchdog on restart" one. Is there a way to achieve
> such functionality?
>
> I'd like to know why "stop watchdog on restart" wasn't implemented via ioctl
> interface? It would be more convenient from user perspective and you can
> control that behavior whenever you want from application layer.
>
Because it is and always was a driver level decision. The function was added
to replace lots of driver level code implementing this functionality.
Overriding it from userspace doesn't make sense because the driver is supposed
to have a reason for disabling it on reboot (for example due to clock issues
or power issues or becasue it has a short hardware timeout).
> I have some thoughts on this problem that solve the aforementioned
> issue with "start watchdog on restart" but I don't think that my solution is
> correct.
>
That functionality doesn't make much sense. It can be accomplished by not
stopping the watchdog on reboot in the first place. And if the watchdog
wasn't running before, it can be started from userspace just before the
reboot.
Guenter
On Wed, 2020-09-02 at 15:19 +0200, Christophe Leroy wrote:
> Isn't it the default expected behaviour for a watchdog ?
It depends on hardware and system requirements. You may have not just one
watchdog device.
> "stop watchdog on restart" is there to keep things under control during
> a wanted machine reboot/restart, while still having the watchdog do its
> job on an unexpected restart.
Yes, that's correct.
> What would be the advantage of an ioctl() compared to the existing way ?
You can control stop/start at any moment for any number of watchdog devices.
Thanks.
On Wed, 2020-09-02 at 06:36 -0700, Guenter Roeck wrote:
> On 9/2/20 6:02 AM, Ivan Mikhaylov wrote:
> > Hello everyone. Currently, the watchdog interface only has "stop watchdog on
> > restart" but lacks a "start watchdog on restart" one. Is there a way to
> > achieve
> > such functionality?
> >
> > I'd like to know why "stop watchdog on restart" wasn't implemented via ioctl
> > interface? It would be more convenient from user perspective and you can
> > control that behavior whenever you want from application layer.
> >
>
> Because it is and always was a driver level decision. The function was added
> to replace lots of driver level code implementing this functionality.
> Overriding it from userspace doesn't make sense because the driver is supposed
> to have a reason for disabling it on reboot (for example due to clock issues
> or power issues or becasue it has a short hardware timeout).
If it's only driver level decision then it makes sense.
> That functionality doesn't make much sense. It can be accomplished by not
> stopping the watchdog on reboot in the first place. And if the watchdog
> wasn't running before, it can be started from userspace just before the
> reboot.
I understand that it can be started from userspace. As example, I want the
watchdog trigger with guarantee that the userspace will be properly shut on
reboot, how can I get it with current interface? Just start before the reboot
doesn't guarantee that it will be triggered or will be triggered in middle
of reboot/restart.
Thanks.
Le 03/09/2020 à 12:23, Ivan Mikhaylov a écrit :
> On Wed, 2020-09-02 at 06:36 -0700, Guenter Roeck wrote:
>> On 9/2/20 6:02 AM, Ivan Mikhaylov wrote:
>>> Hello everyone. Currently, the watchdog interface only has "stop watchdog on
>>> restart" but lacks a "start watchdog on restart" one. Is there a way to
>>> achieve
>>> such functionality?
>>>
>>> I'd like to know why "stop watchdog on restart" wasn't implemented via ioctl
>>> interface? It would be more convenient from user perspective and you can
>>> control that behavior whenever you want from application layer.
>>>
>>
>> Because it is and always was a driver level decision. The function was added
>> to replace lots of driver level code implementing this functionality.
>> Overriding it from userspace doesn't make sense because the driver is supposed
>> to have a reason for disabling it on reboot (for example due to clock issues
>> or power issues or becasue it has a short hardware timeout).
>
> If it's only driver level decision then it makes sense.
>
>> That functionality doesn't make much sense. It can be accomplished by not
>> stopping the watchdog on reboot in the first place. And if the watchdog
>> wasn't running before, it can be started from userspace just before the
>> reboot.
>
> I understand that it can be started from userspace. As example, I want the
> watchdog trigger with guarantee that the userspace will be properly shut on
> reboot, how can I get it with current interface? Just start before the reboot
> doesn't guarantee that it will be triggered or will be triggered in middle
> of reboot/restart.
>
I'm not sure I understand what you want to do.
You want to start the watchdog just before calling 'reboot' but want to
make sure that the watchdog will not reset the board before all
userspace has shut down correctly ?
But what is the purpose of the watchdog then, isn't it there to make
sure that the machine gets reboot within a given timeout anyway in case
some userspace takes too long to shut down ?
Christophe
On Thu, 2020-09-03 at 13:13 +0200, Christophe Leroy wrote:
> You want to start the watchdog just before calling 'reboot' but want to
> make sure that the watchdog will not reset the board before all
> userspace has shut down correctly ?
Yes, just for an example, in the nature exists some aspeed2400/2500 board which
has 2 watchdog devices and 2 spi flash memories. By default it starts from 1 spi
flash. When watchdog triggers, on next boot, it's automatically starts from 2
flash, also you can manually switch from 1 spi flash to 2 with 2 watchdog device
by trigger of it, like transparent reload from 1 spi flash side to 2.
> But what is the purpose of the watchdog then, isn't it there to make
> sure that the machine gets reboot within a given timeout anyway in case
> some userspace takes too long to shut down ?
Usually, yes.
Thanks.