From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 20:09:41 2009 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 3B6CA10656C6; Wed, 21 Jan 2009 20:09:41 +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 F0A488FC12; Wed, 21 Jan 2009 20:09:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 9CE8546B32; Wed, 21 Jan 2009 15:09:40 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0LK9NdS035728; Wed, 21 Jan 2009 15:09:34 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 21 Jan 2009 14:02:52 -0500 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901211402.52967.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 21 Jan 2009 15:09:34 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8885/Wed Jan 21 12:48:08 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Kostik Belousov , jb@freebsd.org, pluknet 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, 21 Jan 2009 20:09:41 -0000 On Wednesday 17 December 2008 8:52:38 am 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: > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x72 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc07fc8c3 > stack pointer = 0x28:0xe4f56a78 > frame pointer = 0x28:0xe4f56b44 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 14 (swi4: clock sio) > [thread pid 14 tid 100002 ] > Stopped at vm_fault+0x1e3: cmpw $0,0x72(%eax) > db> bt > Tracing pid 14 tid 100002 td 0xc63e9c80 > vm_fault(c1066000,c009e000,2,0) at vm_fault+0x1e3 > trap_pfault(e4f56bb0,0,c009effe) at trap_pfault+0x137 > trap(410008,c63e0028,e4f50028,c009effe,c638effe,...) at trap+0x325 > calltrap() at calltrap+0x5 > --- trap 0xc, eip = 0xc08a2cad, esp = 0xe4f56bf0, ebp = 0xe4f56c10 --- > generic_bcopy(c0a63a68,7cf,c0a63a4c,7cf,fffff832) at generic_bcopy+0x41 > vga_txtdraw(c0a63a40,7cf,fffff832,0) at vga_txtdraw+0xbe > scrn_update(c0a63a40,1) at scrn_update+0x22d > scrn_timer(c0a6c1e0) at scrn_timer+0x1e0 > softclock(0) at softclock+0x1f4 > ithread_execute_handlers(c63e8460,c6629800) at ithread_execute_handlers+0xd6 > ithread_loop(c63a7910,e4f56d38,c0a10040,0,c0922ea6,...) at ithread_loop+0x53 > fork_exit(c068d158,c63a7910,e4f56d38) at fork_exit+0x61 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xe4f56d6c, ebp = 0 --- > db> I've seen this panic (or varations of it) on stock 6.x for a long time. I suspect some sort of bug in syscons itself. -- John Baldwin