Thread (5 messages) flat view 5 messages, 4 authors, 2007-05-23

Re: [RFC] BOOKE watchdog and kexec

From: Kumar Gala <hidden>
Date: 2007-05-23 06:13:36

On May 22, 2007, at 10:36 PM, Michael Ellerman wrote:
On Tue, 2007-05-22 at 16:53 -0700, Dave Jiang wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help