Re: cngetc and watchdogs

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

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?  

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.

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

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.  

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

Eduardo