Date: Wed, 21 Jan 2009 14:02:52 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-hackers@freebsd.org Cc: Kostik Belousov <kostikbel@gmail.com>, jb@freebsd.org, pluknet <pluknet@gmail.com> Subject: Re: PRINTF_BUFR_SIZE in freebsd6 Message-ID: <200901211402.52967.jhb@freebsd.org> In-Reply-To: <a31046fc0812170552k31a7434cy9a13ea5c8322e94e@mail.gmail.com> References: <a31046fc0812160423g7508bdbdrb160e9d1ec12b6e3@mail.gmail.com> <a31046fc0812170248g4fa19250j159c645bdcd4ac89@mail.gmail.com> <a31046fc0812170552k31a7434cy9a13ea5c8322e94e@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 17 December 2008 8:52:38 am pluknet wrote: > 2008/12/17 pluknet <pluknet@gmail.com>: > > 2008/12/16 Kostik Belousov <kostikbel@gmail.com>: > >> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200901211402.52967.jhb>