From owner-freebsd-current@FreeBSD.ORG Mon Jun 21 15:43:49 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 06E66106566B for ; Mon, 21 Jun 2010 15:43:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B9D018FC1A for ; Mon, 21 Jun 2010 15:43:48 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5396D46B58; Mon, 21 Jun 2010 11:43:48 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0BEB28A050; Mon, 21 Jun 2010 11:43:47 -0400 (EDT) From: John Baldwin To: Scott Long Date: Mon, 21 Jun 2010 11:21:51 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <9B404DAF-CD34-4799-8DFA-F24AF62F0117@samsco.org> In-Reply-To: <9B404DAF-CD34-4799-8DFA-F24AF62F0117@samsco.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006211121.51649.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 21 Jun 2010 11:43:47 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx 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: Mon, 21 Jun 2010 15:43:49 -0000 On Friday 18 June 2010 10:18:54 pm Scott Long wrote: > On Jun 18, 2010, at 9:11 AM, Alexander Best muenster.de> wrote: > > > On Mon, Jun 7, 2010 at 3:57 PM, John Baldwin wrote: > >> On Saturday 05 June 2010 2:54:15 pm Jille Timmermans wrote: > >>> Scott Long schreef: > >>>> On Jun 4, 2010, at 4:35 PM, Alexander Best wrote: > >>>> > >>>>> hi there. running HEAD, amd64 and r208806 i get this dmesg output > >>>>> which doesn't look right: > >>>>> > >>>>> ada0 at ahcich2 bus 0 scbus3 target 0 lun 0 > >>>>> ada0: ATA-7 SATA 2.x device > >>>>> ada0: 300.000MB/s transferscd0 at ata2 bus 0 scbus2 target 0 lun 0 > >>>>> cd0: Removable CD-ROM SCSI-0 > >>>>> device > >>>>> cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) > >>>>> cd0: cd present [1944656 x 2048 byte records] > >>>>> (SATA 2.x, UDMA6, PIO 8192bytes) > >>>>> ada0: Command Queueing enabled > >>>>> ada0: 238474MB (488395055 512 byte sectors: 16H 63S/T 16383C) > >>>>> > >>>>> > >>>>> my kernel contains: > >>>>> > >>>>> options SC_HISTORY_SIZE=1000 > >>>>> options MSGBUF_SIZE=65536 > >>>>> options PRINTF_BUFR_SIZE=128 > >>>>> > >>>>> might this be caused by one of these lines? > >>>>> > >>>>> cheers. > >>>>> > >>>> > >>>> Can you be more specific about what you think is not right? > >>>> > >>>> Scott > >>> I assume he means that 'cd0 at ata2 ...' is on the same line as the > >>> third ada0 line. After all the cd0-lines, the ada0 line continues. > >>> That shouldn't happen with PRINTF_BUFR_SIZE set, should it? > >> > >> 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 > > > Johns response is off base. I explained the issue prior to him, > please review that. Huh? My point is that the buffer size is not line buffered, but the entire buffer is always output before printf() returns. Thus, if you do: printf("foo"); printf(" bar\n"); Then another CPU or thread can send output in between the "foo" and " bar\n". What people want, aesthetically, is to have per-thread line-buffered output, so each thread would accumulate chars up to a limit or '\n' across multiple calls to printf() and output all of that at once. On the other hand, if something else should be serializing these printfs then they shouldn't interleave even w/o PRINTF_BUFR_SIZE, so I don't see how PRINTF_BUFR_SIZE would fix it. -- John Baldwin