[RFC] BOOKE watchdog and kexec

[Kumar Gala]

On May 22, 2007, at 10:36 PM, Michael Ellerman wrote:

> On Tue, 2007-05-22 at 16:53 -0700, Dave Jiang wrote:
>> What would be the appropriate way to deal with the BOOKE watchdog  
>> in order to
>> properly kexec? The BOOKE watchdog cannot be disabled. With the  
>> current
>> implementation, a watchdog daemon in userland is required to poke the
>> /dev/watchdog continously in order to keep it from going off. In  
>> the kexec
>> situation, the watchdog daemon in userland goes away when the new  
>> kernel is
>> executed. It is very possible that the new kernel can potentially  
>> timeout on a
>> certain hardware device initialization (i.e. SCSI discovery/ 
>> timeout) and causes
>> the watchdog to go off and reset the hardware. The reset is of  
>> course not
>> wanted in this situation.
>>
>> Several solutions comes into mind:
>> 1. Have the kernel timer poke the watchdog. This would ensure  
>> situation
>> described above would never happen. I think x86 does this with NMI  
>> watchdog.
>>
>> 2. Have the watchdog driver spawn a kernel thread to poke the  
>> watchdog at a
>> periodic time. Or perhaps use the delayed-work mechanism to do that.
>>
>> 3. Set the highest bit of the watchdog register so that it does  
>> not expire for
>> 2^32 ticks.
>
> #3 sounds the easiest. You'd set it in machine_kexec_prepare() and  
> then
> have the second kernel restore a sane value. I assume 2^32 ticks is  
> long
> enough to boot?

I haven't looked at the 4xx side, but on fsl parts you can pick any  
of 64-bits in the time base as the transition point, so you should  
have enough time, however maybe setting it to something like the  
panic_timeout or make it configurable is the best choice.

However, I agree that just tweaking the time and restoring it the  
best option.

- k