Date: Mon, 23 Aug 2010 14:39:40 +0300 From: Andriy Gapon <avg@icyb.net.ua> To: Poul-Henning Kamp <phk@phk.freebsd.dk>, Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: freebsd-stable@freebsd.org Subject: Re: Watchdog not being disabled while dumping core Message-ID: <4C725DFC.8000205@icyb.net.ua> In-Reply-To: <85637.1282560826@critter.freebsd.dk> References: <20100823103412.GA21044@icarus.home.lan> <85637.1282560826@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
on 23/08/2010 13:53 Poul-Henning Kamp said the following: > In message <20100823103412.GA21044@icarus.home.lan>, Jeremy Chadwick writes: > >> 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(). > > The good news is that the watchdog hopefully gets your system back > on the air, even if the dumping hangs. > > If it is decided to reset/disarm the watchdog before a dump, please > make that a sysctl tunable. I'd rather add code to take over watchdog from watchdogd and to pat the dog while dumping, perhaps some other crucial places (like right before calling reset). This way we could ensure that system doesn't hang while dumping or in reset routine or etc. Another workaround is to set watchdog timeout large enough for dumping to complete, but that increases time that system is unavailable during a 'hard' hang (e.g. caused by hardware). -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C725DFC.8000205>