From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 13:00:14 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 77C261065670; Sat, 14 Apr 2012 13:00:14 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id 08AEF8FC0C; Sat, 14 Apr 2012 13:00:13 +0000 (UTC) Received: from mr17.lnh.mail.rcn.net ([207.172.157.37]) by smtp02.lnh.mail.rcn.net with ESMTP; 14 Apr 2012 09:00:07 -0400 Received: from smtp04.lnh.mail.rcn.net (smtp04.lnh.mail.rcn.net [207.172.157.104]) by mr17.lnh.mail.rcn.net (MOS 4.3.4-GA) with ESMTP id BLC87494; Sat, 14 Apr 2012 09:00:03 -0400 Received: from 209-6-86-84.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com (HELO jerusalem.litteratus.org.litteratus.org) ([209.6.86.84]) by smtp04.lnh.mail.rcn.net with ESMTP; 14 Apr 2012 08:59:43 -0400 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20361.29886.740093.455933@jerusalem.litteratus.org> Date: Sat, 14 Apr 2012 08:59:42 -0400 To: Jeremie Le Hen In-Reply-To: <20120414090728.GA8798@felucia.tataz.chchile.org> References: <20120414090728.GA8798@felucia.tataz.chchile.org> X-Mailer: VM 7.17 under 21.5 (beta28) "fuki" XEmacs Lucid X-Junkmail-Whitelist: YES (by domain whitelist at mr17.lnh.mail.rcn.net) Cc: Alexander Best , freebsd-current@freebsd.org Subject: Re: howto debug a complete hard reset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 13:00:14 -0000 Jeremie Le Hen writes: > This is probably a sysctl handler that is causing the reboot. You can > run this one-liner to spot the culprit (use sh): > > for i in $(sysctl -Na); do sysctl $i >> ~/sysctl.out; sync; done > > Each sysctl will be called in turn and the output is appended to > a file, but the file will forcibly written to the disk before the > next occurence. Um ... it is my understanding sync(8) does not guarantee pending i/o will be written before it returns, but merely requests this happen irrespective of when it would normally occur. An I mistaken? Robert Huff