Watchdog timer expired, but panic logs not seen
Hi all, I wanted to manipulate the watchdog timer driver to see how it works in deadlocks. In our target qualcom ARM board we use msm_watchdog hardware timer. It has one register WDT0_BARK_TIME, if you set some time, when the timeout occurs it will send and interrupt. In the same driver the interrupt handler is also present, which dumps all the application stacks and calls panic("watchdog bark recieved"); But when is see the logs, immediately after the interrupt generated the device is turning off. It is not even entering the bark_interrupt_handler. (i did put logs in the starting of intr handler and i put another log just before the interrupt occured) My question is this, When watch dog timer expires(hardware watchdog), its interrupt directly resets the system (or) it is treated as an interrupt and a handler is executed. THanks, Sandeep.
On Fri, Sep 9, 2011 at 5:51 PM, sandeep kumar <coolsandyforyou@gmail.com>wrote:
Hi all, I wanted to manipulate the watchdog timer driver to see how it works in deadlocks.
<snip>
My question is this, When watch dog timer expires(hardware watchdog), its interrupt directly resets the system (or) it is treated as an interrupt and a handler is executed.
AFAIK, after the watchdog is triggered, the SoC/processor is completely reset including all the peripherals. The main purpose of a watchdog is to reset a processor which has locked up somewhere in some thread (with interrupts disabled, maybe), effectively starving the thread which is supposed to reset the watchdog periodically. Hence, there is no point in having an interrupt handler to service watchdog interrupt. But maybe some processors may have an option to have an periodic interrupt from watchdog timer, whose only purpose is to reset the watchdog timer. If this interrupt is not serviced for long time then the watchdog would reset the system directly in hardware.
THanks, Sandeep.
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Hi... On Tue, Sep 13, 2011 at 11:55, Kaustubh Ashtekar <ksashtekar@gmail.com> wrote:
On Fri, Sep 9, 2011 at 5:51 PM, sandeep kumar <coolsandyforyou@gmail.com> wrote:
Hi all, I wanted to manipulate the watchdog timer driver to see how it works in deadlocks.
<snip>
My question is this, When watch dog timer expires(hardware watchdog), its interrupt directly resets the system (or) it is treated as an interrupt and a handler is executed.
AFAIK, after the watchdog is triggered, the SoC/processor is completely reset including all the peripherals. The main purpose of a watchdog is to reset a processor which has locked up somewhere in some thread (with interrupts disabled, maybe), effectively starving the thread which is supposed to reset the watchdog periodically.
Just to add, AFAIK watchdog is used in "locked" scenario because it can't be masked and disabled...and it receives highest priority in trap/interrupt by the processors. AFAIK too, in most scenarios, handler is placed to picked up watchdog signal...and it is this handler which is then fix the situation. Only my 2 cents idea... -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
On Wed, Sep 14, 2011 at 2:52 AM, Mulyadi Santosa <mulyadi.santosa@gmail.com>wrote:
Hi...
On Tue, Sep 13, 2011 at 11:55, Kaustubh Ashtekar <ksashtekar@gmail.com> wrote:
On Fri, Sep 9, 2011 at 5:51 PM, sandeep kumar <coolsandyforyou@gmail.com
wrote:
Hi all, I wanted to manipulate the watchdog timer driver to see how it works in deadlocks.
<snip>
My question is this, When watch dog timer expires(hardware watchdog), its interrupt directly resets the system (or) it is treated as an interrupt and a handler is executed.
AFAIK, after the watchdog is triggered, the SoC/processor is completely reset including all the peripherals. The main purpose of a watchdog is to reset a processor which has locked up somewhere in some thread (with interrupts disabled, maybe), effectively starving the thread which is supposed to reset the watchdog periodically.
Just to add, AFAIK watchdog is used in "locked" scenario because it can't be masked and disabled...and it receives highest priority in trap/interrupt by the processors.
AFAIK too, in most scenarios, handler is placed to picked up watchdog signal...and it is this handler which is then fix the situation.
AFAIK, this feature and maybe some other additional features (like Early wakeup) are implementation dependant. Also, for e.g. if code area and/or data area is corrupted due to any reason then even this non-maskable interrupt would not be able to fix the situation. The watchdog's basic idea is to hardware (soft reset) the processor and the peripherals (through the RESET_OUT signal). Some additional features for e.g. of a periodic interrupt before some time the watchdog actually expires may be present in some implementations. This interrupt can be used either to reset the watchdog timer or maybe to do a core dump, for later debugging, before the system actually goes into a watchdog reset. This watchdog features best use case is in embedded systems which where there may not be any human to manually reset the system, in case it is locked up. Kaustubh
participants (3)
-
Kaustubh Ashtekar -
Mulyadi Santosa -
sandeep kumar