Date: Mon, 23 Aug 2010 03:34:12 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: freebsd-stable@freebsd.org Cc: phk@freebsd.org Subject: Watchdog not being disabled while dumping core Message-ID: <20100823103412.GA21044@icarus.home.lan>
next in thread | raw e-mail | index | archive | help
It was brought to my attention that on FreeBSD with a hardware watchdog in use (e.g. ichwd(4) + watchdogd(8)), once the kernel panics, it's quite possible for the watchdog to fire (reboot the system) once the panic has happened. This issue basically inhibits the ability for a system with a hardware watchdog in place to be able to successfully complete doadump(). There's confirmations of this problem dating all the way back to 2005: PR kern/82219, opened in 2005: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/82219 PR bin/145183, opened in 2010 (not sure if this is the same): http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/145183 Confirmation that the problem still exists today (first paragraph): http://lists.freebsd.org/pipermail/freebsd-stable/2010-August/058350.html On Linux, it appears that they've worked around this problem by using what's called a "pretimeout" (basically a way to get the watchdog to become delayed, thus not firing during important tasks): http://www.mjmwired.net/kernel/Documentation/watchdog/watchdog-api.txt According to watchdog(4), it looks like the kernel setting WD_PASSIVE immediately upon entering panic would solve the problem, but the BUGS section indicates WD_PASSIVE hasn't been implemented (returns ENOSYS). Thoughts on solving this dilemma? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100823103412.GA21044>