From owner-freebsd-current@FreeBSD.ORG Fri Jun 18 17:28:52 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3573D106564A for ; Fri, 18 Jun 2010 17:28:52 +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 415EB8FC16 for ; Fri, 18 Jun 2010 17:28:51 +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 UAA23678; Fri, 18 Jun 2010 20:28:49 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C1BACD0.8050707@icyb.net.ua> Date: Fri, 18 Jun 2010 20:28:48 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100517) MIME-Version: 1.0 To: mdf@FreeBSD.org References: <6BEF4925-A058-4EFA-B005-30A01B3132FC@samsco.org> <4C0A9D57.8000900@quis.cx> <201006070957.07376.jhb@freebsd.org> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Jille Timmermans , Alexander Best Subject: Re: strange scsi/CAM related dmesg output 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: Fri, 18 Jun 2010 17:28:52 -0000 on 18/06/2010 18:18 mdf@FreeBSD.org said the following: > On Fri, Jun 18, 2010 at 8:11 AM, Alexander Best > wrote: >> On Mon, Jun 7, 2010 at 3:57 PM, John Baldwin wrote: >>> It can happen because the print buffer size thing is not line-buffered, it is >>> printf-invocation buffered. >> hmmm...can this somehow be fixed? i'm not sure this is specific to >> scsi/cam. the other day i bootd my system and almost all of the dmesg >> output was displayed incorrectly. would increasing PRINTF_BUFR_SIZE >> from 128 to lets say 512 or 1024 solve the issue? > > I think what jhb meant was that we could look for the '\n' and flush > to console there, instead of waiting for the end of the buffer. This > would perhaps have more interleaved full lines, but likely fewer > interleaved partial lines. Not sure if it's relevant here, but want to point out that writing to kernel msgbuf is char-by-char, so any kind of interleaving is possible there and PRINTF_BUFR_SIZE is irrelevant to that. -- Andriy Gapon