tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: cngetc and watchdogs



On Dec 21, 2010, at 9:56 AM, Brian Buhrow wrote:

>       Hello.  I have a question about this.  If I understand what this
> change does correctly, you're trying to keep the hardware watchdog from
> firing while you're in DDB, right?  The question is, is this an optional
> change?  That is, can I change the behavior on the fly while the machine is
> running?  For example, I may want to have the ability to debug a problem on
> a machine, but if the problem occurrs infrequently, which is why I presume
> you need this feature at all, there may be times when I want the hardware
> watchdog to fire since I'm not near the machine to look into the issue, and
> I might want it to continue working, after a fashion, in my absence.  But,
> if I'm standing by, waiting for the problem to occurr, I want it to stick
> at DDB when it falls into it.
>       I ran into this issue as well while debugging some modules, but
> decided the current behavior was fine, since if I wasn't at the machine, I
> wanted it to carry on anyway.  The problem was that building a debugging
> environment looked different thana production environment.

If the watchdog fires, you typically want one of two actions.
reset the system (unattended) or drop into the debugger (attended)
Let's assume the watchdog timer fires which causes a panic.
You can controlwhether you drop into ddb with sysctl.

sysctl -w ddb.onpanic=1 makes the system stop in ddb on a panic
sysctl -w ddb.onpanic=0 doesn't




Home | Main Index | Thread Index | Old Index