On Sat, 17 Jul 2010, David Young wrote:
It is a generic capability. ...
That's the conclusion I came to.
... ISTM watchdog timers should eventually be
refactored in this way: each watchdog timer in the system should have a
corresponding pseudo-device, an instance of wdog(4). wdog(4) provide
On Sat, Jul 17, 2010 at 05:29:19AM -0700, Paul Goyette wrote:
> On Sat, 17 Jul 2010, David Young wrote:
> >3 Watchdog prevents suspension
>
> As I indicated, this is fairly easy to do, simply check if the w-dog
> is armed or not.
>
> The attached patch provides an ipmi_suspend() method to impleme
On Sat, 17 Jul 2010, Jukka Ruohonen wrote:
On Fri, Jul 16, 2010 at 06:14:39PM -0700, Paul Goyette wrote:
Would it be sufficient for ipmi(4) to refuse to suspend (return false
from the suspend method) if the watchdog is active?
Or should it make some sort of effort to disable the watchdog, and
On Sat, 17 Jul 2010, David Young wrote:
ipmi(4) should probably not suspend if its watchdog timer is active.
Would it be sufficient for ipmi(4) to refuse to suspend (return
false from the suspend method) if the watchdog is active?
Yes. I think that's the right thing to do for now.
This is
I recently had the following panic on a 4.0/amd64 machine.
Everything below has been manually typed in from photographs taken from the
console screen. I don't have a dump.
kernel: protection fault trap, code=0
Stopped in pid 15.1 (pagedaemon) at netbsd:uvm_map_lookup_entry+0x1b:
cmpq
