PRINTF_BUFR_SIZE in freebsd6

[John Baldwin]

On Wednesday 17 December 2008 8:52:38 am pluknet wrote:
> 2008/12/17 pluknet <pluknet at gmail.com>:
> > 2008/12/16 Kostik Belousov <kostikbel at 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