On Tue, May 27, 2008 at 6:31 PM, T Ziomek wrote: > On Tue, May 27, 2008 at 06:27:58PM -0400, Mike Frysinger wrote: >> On Tue, May 27, 2008 at 5:57 PM, David VomLehn wrote: >> > Continuous Logging for Watchdog Timer Expiration >> > ------------------------------------------------ >> > We run with a watchdog timer that can reboot the system. When we reboot, we >> > lose all of our status, making it very difficult to determine what went >> > wrong. Fortunately, there is only one major cause of not refreshing the >> > watchdog--a driver disabled interrupts for so long that the timer function >> > that resets the watchdog timer never had a chance to run. So, a way to log >> > what functions were enable and disabling interrupts on a continuous basis, >> > along with a memory section that wouldn't be overwritten on reboot, would >> > allow capturing the cause for these otherwise "silent" reboots. >> >> how do you propose addressing that ? hardware watchdogs reset the >> hardware, so there is nothing software can do to recover information >> like register state. as soon as the watchdog timer expires, the state >> is gone forever. >> -mike > > If I understand correctly David is talking about logging some trace-like > info (so it exists before a HW watchdog expires), and having it somewhere > "safe" from being disturbed by a HW reset. in my mind, such a thing isnt really bound to the watchdog. while the watchdog may be a common source, there are plenty of other sources which would be addressed the same way. call it something like "Continuous Logging for Unexpected Resets". -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
