[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: cngetc and watchdogs
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
> 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.
Main Index |
Thread Index |