From owner-freebsd-stable@FreeBSD.ORG Wed May 29 07:11:43 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CE721A59 for ; Wed, 29 May 2013 07:11:43 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:211]) by mx1.freebsd.org (Postfix) with ESMTP id 9CDCFFB6 for ; Wed, 29 May 2013 07:11:43 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta11.emeryville.ca.mail.comcast.net with comcast id hjBi1l0031bwxycABjBiKi; Wed, 29 May 2013 07:11:42 +0000 Received: from jdc.koitsu.org ([67.180.84.87]) by omta18.emeryville.ca.mail.comcast.net with comcast id hjBh1l00A1t3BNj8ejBhAv; Wed, 29 May 2013 07:11:42 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 379C473A33; Wed, 29 May 2013 00:11:41 -0700 (PDT) Date: Wed, 29 May 2013 00:11:41 -0700 From: Jeremy Chadwick To: Dominic Fandrey Subject: Re: System doesn't dump Message-ID: <20130529071141.GA90903@icarus.home.lan> References: <51A5A322.1020503@bsdforen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51A5A322.1020503@bsdforen.de> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369811502; bh=/nolIBy/nD6opeFhI3PPKC9OCJeJzdIt/hYreTEmsJI=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=KxOC0B+dNdL4cmKpUT/y8Qk+nnd52wJ/OunPOmS6r3ONeSLi2jFjcZJvq85vEWHKc yh2wnB9+pxI2fMzUknGkoCQ3nmYhW0EDCFppoJmecqOyhfPMyJqcEI0fT/4y/Kgo/5 njw6e4A1/fvFnVwF6GiPFJL4dOyTq+qAstRgNz5SDD9wpoG3AT4ZnQmQISnP10uugM rZXTw9agKsN4fKRb3j5BarHkLV91naElu9HCbW5EoaZ5dupk8EcWVs++vXuW5zocT1 pcXyWSX2VOX9y6X93ezS91NnFECEzrAUH7Z/wk2qLl7zqsTd5aMGNz5qgo3fPN1IKg XYu8xEpB2df1Q== Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 07:11:43 -0000 On Wed, May 29, 2013 at 08:41:38AM +0200, Dominic Fandrey wrote: > I have a number of actions that reliably panic the system, such as > performing shutdown -p (yes I'm booting into an inconsistent file > system every time). Both with my notebook and my workstation. > > However I cannot get the system to dump. > > dumpdir=/var/crash > and I've tried ada0s2b, /dev/ada0s2b, label/5swap, /dev/label/5swap and AUTO > for dumpdev to no avail. > > The swap partition is 16g, the machines have 8g RAM and there's plenty > of hard disk space available for /var/crash. > > I'm looking for that secret, undocumented trigger, that makes the > system dump if a panic occurs. Once upon a time dumping just worked > if the swap partition was large enough. I miss those olden days. Foremost: the fact you did not disclose your FreeBSD version (and SVN rev if you have it) nor architecture is disappointing. It matters more than you think. Please disclose it. Onward ho... If you have VGA console access, try dropping to db> and issuing the command "call doadump" (possibly preceded by "panic"). If you have serial console access, there are ways to drop to ddb but it depends on your kernel config (look for BREAK_TO_DEBUGGER and ALT_BREAK_TO_DEBUGGER in /sys/conf/NOTES). "Break" with serial, by the way, means a serial-level break signal (often why I prefer ALT_BREAK_TO_DEBUGGER). After doing "call doadump" you should definitely see the kernel dumping memory to swap (it gives a progress indicator of sorts). Google for the phrase "call doadump" and look at some of the results to get an idea of what the output normally is during that phase, for comparison. If you don't see such, I'm sure many of the kernel folks here can help figure out why. See sysctl debug.ddb.scripting.scripts for what should get automatically done on a panic. This may or may not be affected by ddb_enable="yes" in rc.conf (which mandates DDB being enabled in your kernel) -- I can't remember though, so someone else may want to comment. If your issue is that the kernel actually *does* dump memory to swap but that on boot-up savecore(8) doesn't recover the memory dump and populate relevant files in /var/crash: that's a separate issue that has been discussed for probably 10 years or longer with (to my knowledge) no definitive explanation. Theories presented (going off of memory here) were that that something ended up writing over parts of the "panic metadata" on the swap disk/slice/etc. and thus savecore(8) finds nothing. This is why rc scripts/etc. have to make sure to look for the swap "panic metadata" and run savecore(8) **before** issuing dumpon(8). My opinion, others' may vary: Stick with using dumpdev="auto" in rc.conf, assuming you have a /etc/fstab entry of "swap" somewhere. Swap should ideally be a partition or slice, not something abstracted out by other layers (see above paragraph for why I advocate that, but my additional opinion is that when it comes to getting a kernel dump and system configurations, KISS principle applies heavily. If your system is crashing, the last thing you want to deal with is why you can't get a kernel dump -- you could spend more time doing that than you do getting the panic info + debugging the actual crash), but again, this is my own opinion and there are legitimate other opinions as well -- I just follow what I do because I know it works. Likewise I always get wary of people's setups when I start seeing labels mentioned. *waves cane* Screw all this newfandangled stuff. :-) -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |