Steve deRosier
2013-02-14 18:34:58 UTC
I'd like to know what is the best way to handle the watchdog timer in
Linux? I've reviewed the docs and the watchdog framework and it's not
really fitting my needs.
The system I'm upgrading turns on the WDT very early in the
boot-loader There is code sprinkled through the boot-loader and then
sprinkled through various init calls in Linux 2.4 that kick the WDT
before it times out all through boot. Eventually when userspace comes
up, a user program opens the WDT device and takes control of kicking
it via an ioctl into a custom gpio driver. Of course there's still a
few spots in the kernel and drivers that seem to kick the WDT during
normal operation, so it's still a remote possibility that a reset
wouldn't occur even if the user-space program died.
As you might imagine, I don't like that the original coders simply,
via trial and error, sprinkled a WDT kick call randomly through all
the various kernel init calls in order to keep things going. I was
hoping that with a formal WDT framework in 3.x that the kernel had
some sort of hook to handle it in a clean and accepted manner.
The kernel driver framework seems to assume that the WDT will only be
handled by userspace and indeed doesn't start the WDT until the device
is opened. As near as I can tell, there's no provision to handle a WDT
that's started during or before kernel boot. True?
It's important to note that the WDT on the MCF5235, once started, can
not be disabled. And once it's time period is set, that can't be
changed either. It's set at a max interval of about 8 seconds.
I have thought of a few ways to proceed:
1. Implement a standard WDT that doesn't start till userspace opens
the device and convince the system designers that's OK.
2. Implement the existing strategy and just sprinkle the kicking code
through the kernel init and drivers, and add the standard WDT that
userspace can open and take over with.
3. Implement some kernel process that takes over automatic periodic
kicking until the real WDT driver is opened the first time by
userspace. Then that process gets disabled.
Anyway, any thoughts? How have other Coldfire projects handed the WDT in Linux?
Thanks,
- Steve
Linux? I've reviewed the docs and the watchdog framework and it's not
really fitting my needs.
The system I'm upgrading turns on the WDT very early in the
boot-loader There is code sprinkled through the boot-loader and then
sprinkled through various init calls in Linux 2.4 that kick the WDT
before it times out all through boot. Eventually when userspace comes
up, a user program opens the WDT device and takes control of kicking
it via an ioctl into a custom gpio driver. Of course there's still a
few spots in the kernel and drivers that seem to kick the WDT during
normal operation, so it's still a remote possibility that a reset
wouldn't occur even if the user-space program died.
As you might imagine, I don't like that the original coders simply,
via trial and error, sprinkled a WDT kick call randomly through all
the various kernel init calls in order to keep things going. I was
hoping that with a formal WDT framework in 3.x that the kernel had
some sort of hook to handle it in a clean and accepted manner.
The kernel driver framework seems to assume that the WDT will only be
handled by userspace and indeed doesn't start the WDT until the device
is opened. As near as I can tell, there's no provision to handle a WDT
that's started during or before kernel boot. True?
It's important to note that the WDT on the MCF5235, once started, can
not be disabled. And once it's time period is set, that can't be
changed either. It's set at a max interval of about 8 seconds.
I have thought of a few ways to proceed:
1. Implement a standard WDT that doesn't start till userspace opens
the device and convince the system designers that's OK.
2. Implement the existing strategy and just sprinkle the kicking code
through the kernel init and drivers, and add the standard WDT that
userspace can open and take over with.
3. Implement some kernel process that takes over automatic periodic
kicking until the real WDT driver is opened the first time by
userspace. Then that process gets disabled.
Anyway, any thoughts? How have other Coldfire projects handed the WDT in Linux?
Thanks,
- Steve