From owner-freebsd-stable@FreeBSD.ORG Sun Aug 18 11:57:01 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6C10B3F3 for ; Sun, 18 Aug 2013 11:57:01 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id DE39023D5 for ; Sun, 18 Aug 2013 11:57:00 +0000 (UTC) Received: from mobileKamikaze.norad (HSI-KBW-134-3-231-194.hsi14.kabel-badenwuerttemberg.de [134.3.231.194]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id 9B02486184; Sun, 18 Aug 2013 13:56:58 +0200 (CEST) Message-ID: <5210B689.2030703@bsdforen.de> Date: Sun, 18 Aug 2013 13:56:57 +0200 From: Dominic Fandrey MIME-Version: 1.0 To: Jeremy Chadwick Subject: Re: System doesn't dump References: <51A5A322.1020503@bsdforen.de> <20130529071141.GA90903@icarus.home.lan> In-Reply-To: <20130529071141.GA90903@icarus.home.lan> Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: 7bit 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: Sun, 18 Aug 2013 11:57:01 -0000 After a long time I got my system to make all the right noises (I think), still without it actually dumping, though. On 29/05/2013 09:11, Jeremy Chadwick wrote: > 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. Branch is stable/9 revision r254418. Architecture is amd64: # uname -a FreeBSD mobileKamikaze.norad 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0 r254418: Fri Aug 16 22:15:55 CEST 2013 root@mobileKamikaze.norad:/usr/obj/HP6510b-91/amd64/usr/src/sys/HP6510b-91 amd64 > If you have VGA console access, try dropping to db> and issuing the > command "call doadump" (possibly preceded by "panic"). KMS. So no ... > 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). No serial access. Unless this is somehow possible over USB. > ... > 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. # sysctl debug.ddb debug.ddb.capture.bufsize: 49152 debug.ddb.capture.inprogress: 0 debug.ddb.capture.maxbufsize: 5242880 debug.ddb.capture.bufoff: 0 debug.ddb.scripting.unscript: debug.ddb.scripting.scripts: lockinfo=show locks; show alllocks; show lockedvnods kdb.enter.panic=textdump set; capture on; run lockinfo; show pcpu; bt; ps; alltrace; capture off; call doadump; reset kdb.enter.witness=run lockinfo debug.ddb.textdump.do_version: 1 debug.ddb.textdump.do_panic: 1 debug.ddb.textdump.do_msgbuf: 1 debug.ddb.textdump.do_ddb: 1 debug.ddb.textdump.do_config: 1 debug.ddb.textdump.pending: 0 > If your issue is that the kernel actually *does* dump memory to swap but > that on boot-up savecore(8) doesn't recover ... I cannot be perfectly positive, because a minidump is written in no time, but I do not think that is the issue. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?