Hi Guenter,
On 24 May 2015 at 04:44, Guenter Roeck linux@roeck-us.net wrote:
On 05/23/2015 01:27 PM, Timur Tabi wrote:
Guenter Roeck wrote:
However, the pretimeout concept assumes that there are two timers which can be set independently. As you had pointed out earlier, and as the specification seems to confirm, that is not the case here. As such, I don't really understand why and how the pretimeout / timeout concept would add any value here and not just make things more complicated than necessary. Maybe I am just missing something.
It might be possible to load a new value into the WOR register after the WS0 interrupt occurs. That is, in the interrupt handler, we can do something like this:
if (status & SBSA_GWDT_WCS_WS0) // write new WOR value, // then ping watchdog so that it's loaded
I'm not convinced that it's worth it, however. It would require interrupts to still be working when WS0 times out, which somewhat defeats the purpose of a watchdog.
If I understand the specification correctly, reloading the register would result in another WS0, not in WS1. That isn't really what we would want to happen.
Yes, you are 100% correct. In SBSA: --------------- An explicit watchdog refresh occurs when one of a number of different events occur: (1) The Watchdog Refresh Register is written. (2) The Watchdog Offset Register is written. (3) The Watchdog Control and Status register is written. In the case of an explicit refresh the Watchdog Signals are cleared. --------------- So, for the second timeout, we can only use WOR.(but maybe we can write WCV in the WS0 routine to make the second timeout longer, if we really need a long time for panic) If we write WOR , that will clean WCS, then the system go back to first timeout stage.
But for the first timeout, we can use WOR (that means the two timeout stages will be the same, in another world, WS0==WS1*2 ) or we can write WCV directly.
And writing WCV will not trigger an explicit watchdog refresh, that is what I am doing to set up pretimeout.
Reloading the register would normally be done in the crashdump kernel, if it is loaded, to give it time to actually take the crashdump. But that is post-restart, not pre-restart.
Thanks, Guenter