From owner-freebsd-current@FreeBSD.ORG Fri Oct 12 13:39:41 2007 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 E660A16A420 for ; Fri, 12 Oct 2007 13:39:41 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from mail.ciam.ru (ns.ciam.ru [213.247.195.75]) by mx1.freebsd.org (Postfix) with ESMTP id 9487B13C46A for ; Fri, 12 Oct 2007 13:39:41 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from dhcp250-210.yandex.ru ([87.250.250.210]) by mail.ciam.ru with esmtpa (Exim 4.x) id 1IgKBv-000Avl-5W; Fri, 12 Oct 2007 17:04:35 +0400 Message-ID: <470F7082.3050200@FreeBSD.org> Date: Fri, 12 Oct 2007 17:02:58 +0400 From: Sergey Matveychuk User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Kostik Belousov References: <200710120913.47380.joao@matik.com.br> <20071012122049.GA96557@eos.sc1.parodius.com> <20071012122948.GM2180@deviant.kiev.zoral.com.ua> In-Reply-To: <20071012122948.GM2180@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , JoaoBR Subject: Re: what is this: SdMaP0? 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, 12 Oct 2007 13:39:42 -0000 Kostik Belousov wrote: > On Fri, Oct 12, 2007 at 05:20:49AM -0700, Jeremy Chadwick wrote: >> On Fri, Oct 12, 2007 at 09:13:47AM -0300, JoaoBR wrote: >>> somebody has a translation for this in my dmesg of amd64? >>> SdMaP0:: AP1 6C0P.U0 0#0M1B /Lsa utnrcahnesdf!e >> Here's the translation, and look closely: >> >> SMP: AP CPU #1 Launched! >> da0: 160.000MB/s transfe >> >> And yes, I have seen this before on amd64. My guess is that it's two >> things in the kernel trying to output to the console buffer at the exact >> same time, and there's no mutex lock being done. > > I think that setting the option PRINTF_BUFR_SIZE 128 could help in this > situation. BTW, note my kern/116310. It fixes relate issue for log() function. But I did not touch kernel's printf(). Our logs have no junk now. -- Dixi. Sem.