From owner-freebsd-stable@FreeBSD.ORG Mon Aug 23 11:39:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1ECF21065673 for ; Mon, 23 Aug 2010 11:39:49 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 67C0D8FC1B for ; Mon, 23 Aug 2010 11:39:47 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA15744; Mon, 23 Aug 2010 14:39:41 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C725DFC.8000205@icyb.net.ua> Date: Mon, 23 Aug 2010 14:39:40 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100517) MIME-Version: 1.0 To: Poul-Henning Kamp , Jeremy Chadwick References: <20100823103412.GA21044@icarus.home.lan> <85637.1282560826@critter.freebsd.dk> In-Reply-To: <85637.1282560826@critter.freebsd.dk> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Watchdog not being disabled while dumping core X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 11:39:49 -0000 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