From owner-freebsd-questions@FreeBSD.ORG Sun Feb 17 03:02:43 2008 Return-Path: Delivered-To: questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FBF116A41A for ; Sun, 17 Feb 2008 03:02:43 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from chen.org.nz (chen.org.nz [202.89.146.5]) by mx1.freebsd.org (Postfix) with ESMTP id E302A13C457 for ; Sun, 17 Feb 2008 03:02:42 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: by chen.org.nz (Postfix, from userid 1000) id C885328438; Sun, 17 Feb 2008 16:02:41 +1300 (NZDT) Date: Sun, 17 Feb 2008 16:02:41 +1300 From: Jonathan Chen To: Robert Huff Message-ID: <20080217030241.GA34692@osiris.chen.org.nz> References: <200802161142.53044.FreeBSD@insightbb.com> <20080216215521.GB12555@osiris.chen.org.nz> <18359.26373.750798.755610@jerusalem.litteratus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18359.26373.750798.755610@jerusalem.litteratus.org> User-Agent: Mutt/1.4.2.3i Cc: questions@freebsd.org, Steven Friedrich Subject: Re: Shutdown anomaly X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2008 03:02:43 -0000 On Sat, Feb 16, 2008 at 05:43:17PM -0500, Robert Huff wrote: > Jonathan Chen writes: > > > > I am seeing the following messages, which appear to indicate a memory > > > overwrite: > > > Waiting (max 60 seconds) for system processs 'vnlru' to stop...done > > > Waiting (max 60 seconds) for system processs 'bufdaemon' to stop...done > > > a > > > iStyinncgi n(gm adxi s6k0s ,s evcnoonddess) rfeomra isnyisntge.m. .pr0o > > > cess 'syncer' to stop...0 0 done > > > All buffers synced. > > > Uptime: 8m9s > > > > It's an interleaved buffer messages on SMP systems. The problem is > > known, but I haven't heard of a proposed solution yet. > > There is no fix. > The workaround is to increase the size of the kernel printf() > buffer. I don't remember how you do that ... but this is not a new > issue - chech the archives for details. The PRINTF_BUFR_SIZE=128 workaround doesn't work on the few systems I've seen the issue on; but if you're interested, one way to do it is: include GENERIC ident GENERIC-1 options PRINTF_BUFR_SIZE=128 Cheers -- Jonathan Chen ---------------------------------------------------------------------- "If everything's under control, you're going too slow" - Mario Andretti