Re: cngetc and watchdogs

[Matt Thomas <matt%3am-software.com@localhost>]

On Dec 20, 2010, at 4:34 PM, Eduardo Horvath wrote:

> On Mon, 20 Dec 2010, Matt Thomas wrote:
> 
>> There's a deadly embrace between watchdogs and cngetc.  While cngetc is 
>> looping at splserial, callouts are blocked, let alone letting user processes 
>> run.
>> 
>> So if you are stuck at the ddb prompt, eventually the watchdog will fire 
>> because you didn't type fast enough.
>> 
>> I've added a new class of hook to do this, critpoll (critical poll).
>> 
>> I want to change the current semantics of cn_getc from spin forever to poll 
>> for a character and return -1 if no character is ready or >= 0 for valid 
>> input.  The definition allows serial drivers to change as needed.
>> 
>> The diff to dev/cons.c is at http://www.netbsd.org/~matt/cons-diff.txt
>> The diff to dev/ic/com.c is at http://www.netbsd.org/~matt/com-diff.txt
>> 
>> I've been using this for 6 months with no problems.
> 
> Could you explain your reasoning a bit more?  

I have a system where the firmware starts the kernel with the watchdog
active and the watchdog can't be disabled.

> In my experience this usually comes down to a policy decision.  If you 
> really want to debug a system you usually want to turn off the watchdog 
> first.  If the system is in production and somehow it drops to the kernel 
> (panic or glitch on the serial line?) the desired behavior usually 
> involves a reset to get the system running again.

then you really shouldn't have the system to drop into ddb on panic.
If you elect to drop into ddb, you should at least be a chance to
diagnose the problem.

> OTOH, another option is to use hooks in DDB entry and exit to disable or 
> change the watchdog interval to somehing appropriate.

The system I use this can't change the watchdog once it's enabled
and it's always enabled.

> Both disabling the watchdog on entry and having DDB pat the watchdog (the 
> solution you are proposing) are useful in certain circumstances, but in 
> general I find them suspect.  

Again, that won't for this syste,

> I'm also a bit concerned about allowing something to modify the machine 
> state while you're using DDB to debug it.

You do that anyways by DDB disabling interrupts.  This is quite similar to that.