From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 17 16:40:44 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B0221065687 for ; Wed, 17 Dec 2008 16:40:44 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id EB3598FC2F for ; Wed, 17 Dec 2008 16:40:43 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so2372500yxb.13 for ; Wed, 17 Dec 2008 08:40:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=qvNhEq0y72exixNgmdtGvIGCEUD5lrLqPlIjPDZgiTY=; b=K6VROwX4Ofnpy7DhKtghbfREaeYWJGrHncHOhVttN/l0F31oGkuuISbRqx0RVPW+uI RzyXM8CkCih3Ar1CgbL6Lp4b6XAJkcrWvleKJ8Uf8/AXqCa+OHTTWo+NmsNViEMiPDlR qhDR1gxowIuN0K+T6K8nVrtdd+Gu9ph9DJpdQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=XAVYorwrMNhc8lWa836Q1tuWVGSIZ83b9E/6WitfqZysynKXZo104Y60Zvi1jYd6zz V2dMP1ESlsZqZKrqKQtlzFbQegoCK6jUfVIUQg/uvHe8tCbcjgND8qkHm2iaKJeDEUmX Z1dy+v1da1H/a/bn2ji+ix8SB2vDzwPOOOz1s= Received: by 10.90.99.6 with SMTP id w6mr504609agb.81.1229532042853; Wed, 17 Dec 2008 08:40:42 -0800 (PST) Received: by 10.90.91.14 with HTTP; Wed, 17 Dec 2008 08:40:42 -0800 (PST) Message-ID: Date: Wed, 17 Dec 2008 19:40:42 +0300 From: pluknet To: "Paul B. Mahol" In-Reply-To: <3a142e750812170804v345457f0n1261baa418111a2f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081216134035.GU2038@deviant.kiev.zoral.com.ua> <3a142e750812170610r25a48762y845010c6898f52d4@mail.gmail.com> <3a142e750812170804v345457f0n1261baa418111a2f@mail.gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: PRINTF_BUFR_SIZE in freebsd6 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2008 16:40:44 -0000 2008/12/17 Paul B. Mahol : > On 12/17/08, pluknet wrote: >> 2008/12/17 Paul B. Mahol : >>> On 12/17/08, pluknet wrote: >>>> 2008/12/17 pluknet : >>>>> 2008/12/16 Kostik Belousov : >>>>>> On Tue, Dec 16, 2008 at 03:23:28PM +0300, pluknet wrote: >>>>>>> Hi. >>>>>>> >>>>>>> Could the PRINTF_BUFR_SIZE option be safely merged into RELENG_6 >>>>>>> without >>>>>>> merging a possible underlining infrastructure and breaking something >>>>>>> else? >>>>>>> I want to use it in my custom freebsd6 because I see "interspersed >>>>>>> strings >>>>>>> written from different CPUs at the same time": >>>>>>> >>>>>>> uuusseseerrvmrem: vlmivmeimtme :e mx:ceed eldi bly 2i89m68m (iihttt t >>>>>>> pde) eaxtx cfcorke1 22e3e >>>>>>> deded ebyd by28 296898 68(h t(tpdh) att ftorkp1 22d3 >>>>>>> ) at fork1 223 >>>>>>> >>>>>>> I'm talking about only merging kern/subr_prf.c 1.126, 1.128, 1.129. >>>>>>> >>>>>>> Thanks. >>>>>> >>>>>> I did a backport of the option some time ago, see >>>>>> http://people.freebsd.org/~kib/misc/releng_6_printf_bufr.3.patch >>>>>> >>>>> >>>>> Thank you! >>>>> >>>>> 6.3 system panics (many page faults, one after another) early at boot >>>>> without the option, and boots with it in the QEMU environment. >>>>> Next step to test it on a real (and SMPable) hardware. >>>>> >>>> >>>> Now tested on a real 2xXeon 3.0 w/ HTT enabled w/ PRINTF_BUFR_SIZE >>>> enabled. >>>> >>>> Received the following panic: >>> >>> And how big is PRINTF_BUFR_SIZE ? >> >> Hi. >> >> I set options PRINTF_BUFR_SIZE=128 >> >> And maybe it's not enough (?) because I stress-tested server triggering >> to appear many kernel messages simultaneously. >> I don't know coherence between buffer size and this panic though. > > How long such kernel messages are? 48 symbols plus length of a process name... it added 6 in my case, i.e. 54 symbols totally. -- wbr, pluknet