Pawel Worach wrote: > Divacky Roman wrote: > >> #22 0xc0493087 in softclock (dummy=0x0) at atomic.h:365 >> #23 0xc04768a3 in ithread_loop (arg=0xc1577480) >> at /usr/src/sys/kern/kern_intr.c:546 >> #24 0xc0475be9 in fork_exit (callout=0xc0476761 <ithread_loop>, >> arg=0xc1577480, frame=0xd3fc3d48) at >> /usr/src/sys/kern/kern_fork.c:790 >> #25 0xc057ef5c in fork_trampoline () at >> /usr/src/sys/i386/i386/exception.s:208 >> > > I have seen the same thing but only these four frames in DDB, happened > during > boot. I'll see if I can get a dump with it, my kernel is built with -O. > It occurred right after enabling pf(4) on boot. (kgdb) printf "%s", msgbufp->msg_ptr ... <118>Feb 8 21:08:14 <kern.info> cookie kernel: pflog0: promiscuous mode enabled pf: started <118>pf enabled altq: started Fatal trap 12: page fault while in kernel mode fault virtual address = 0x1c ---Type <return> to continue, or q <return> to quit--- fault code = supervisor write, page not present instruction pointer = 0x8:0xc05222b7 stack pointer = 0x10:0xe32f4c94 frame pointer = 0x10:0xe32f4cd4 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 = 28 (swi4: clock sio) (kgdb) bt #0 doadump () at pcpu.h:159 #1 0xc046dbf5 in db_fncall (dummy1=0, dummy2=0, dummy3=1999, dummy4=0xe32f4a84 " \uffffn\uffff\f") at /usr/src/sys/ddb/db_command.c:531 #2 0xc046d982 in db_command (last_cmdp=0xc06eb424, cmd_table=0x0, aux_cmd_tablep=0xc06be500, aux_cmd_tablep_end=0xc06be504) at /usr/src/sys/ddb/db_command.c:349 #3 0xc046da95 in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 #4 0xc046fc15 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:221 #5 0xc0531a57 in kdb_trap (type=0, code=0, tf=0xe32f4c54) at /usr/src/sys/kern/subr_kdb.c:421 #6 0xc0673b04 in trap_fatal (frame=0xe32f4c54, eva=0) at /usr/src/sys/i386/i386/trap.c:801 #7 0xc06737f2 in trap_pfault (frame=0xe32f4c54, usermode=0, eva=28) at /usr/src/sys/i386/i386/trap.c:724 #8 0xc0673350 in trap (frame= {tf_fs = -483459048, tf_es = -1068367856, tf_ds = 16, tf_edi = 4, tf_esi = 6, tf_ebp = -483439404, tf_isp = -483439488, tf_ebx = 0, tf_edx = -701736880, tf_ecx = 21969, tf_eax = -1037546256, tf_trapno = 12, tf_err = 2, tf_eip = -1068358985, tf_cs = 8, tf_eflags = 66118, tf_esp = 0, tf_ss = 800582919}) at /usr/src/sys/i386/i386/trap.c:414 #9 0xc0663e4a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #10 0xe32f0018 in ?? () #11 0xc0520010 in thread_exit () at /usr/src/sys/kern/kern_thread.c:615 #12 0xc04f9978 in ithread_loop (arg=0xc227a480) at /usr/src/sys/kern/kern_intr.c:546 #13 0xc04f887f in fork_exit (callout=0xc04f97d0 <ithread_loop>, arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:790 #14 0xc0663eac in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208 (kgdb) l *0xc05222b7 0xc05222b7 is in softclock (atomic.h:154). 149 atomic.h: No such file or directory. in atomic.h (kgdb) frame 12 #12 0xc04f9978 in ithread_loop (arg=0xc227a480) at /usr/src/sys/kern/kern_intr.c:546 546 ih->ih_handler(ih->ih_argument); (kgdb) list 541 mtx_unlock(&ithd->it_lock); 542 goto restart; 543 } 544 if ((ih->ih_flags & IH_MPSAFE) == 0) 545 mtx_lock(&Giant); 546 ih->ih_handler(ih->ih_argument); 547 if ((ih->ih_flags & IH_MPSAFE) == 0) 548 mtx_unlock(&Giant); 549 } 550 (kgdb) print *ih $3 = {ih_handler = 0xc0522000 <softclock>, ih_argument = 0x0, ih_flags = -2147483648, ih_name = 0xc06b998b "clock", ih_ithread = 0xc227a480, ih_need = 1, ih_next = {tqe_next = 0xc23e7940, tqe_prev = 0xc227a4b0}, ih_pri = 52 '4'} Frame #10 is strange, I'm fairly certain it was something like "softclock(0,0,0,0,0)" in the ddb trace unfortunetly IBM decided to put a parallel port instead of a serial one on my ThinkPad so I can't capture that easily. Kernel was built with -O according to 0>me_at_cookie /usr/obj/usr/src/sys/IBMT41> make -V CFLAGS -O -pipe -march=pentium2 -Wall ... config has SCHED_4BSD, PREEMPTION and ADAPTIVE_GIANT, no SMP, WITNESS or INVARIANTS. mpsafe{vfs,net,vm} is 1 What else is strange is that I have set debug.debugger_on_panic=0 debug.trace_on_panic=1 in sysctl.conf but the box dropped to DDB on panic, shouldn't it dump automagically with debug.debugger_on_panic set to 0 ? -- PawelReceived on Tue Feb 08 2005 - 19:55:19 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:27 UTC