On 08-Dec-2003 Robin Breathe wrote: > I've been experiencing the following repeatable panic on recent > -CURRENT. This one is against RELENG_5_2, as of around 18:00 UT today. > Until now I've not been able to get a dump, but thankfully one's finally > come :) If you can reproduce the panic with INVARIANTS, it would be very useful to know which, if any, assertions it trips. > -- > panic messages: > --- > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x1103bd6c > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc054150d > stack pointer = 0x10:0xddcad980 > frame pointer = 0x10:0xddcad984 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 717 (ngctl) > Dumping 511 MB > 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 > 320 336 352 368 384 400 416 432 448 464 480 496 > --- > Reading symbols from /boot/kernel/acpi.ko...done. > Loaded symbols for /boot/kernel/acpi.ko > Reading symbols from /boot/kernel/ng_socket.ko...done. > Loaded symbols for /boot/kernel/ng_socket.ko > Reading symbols from /boot/kernel/ng_eiface.ko...done. > Loaded symbols for /boot/kernel/ng_eiface.ko >#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 > 240 dumping++; > (kgdb) bt >#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 >#1 0xc044c225 in db_fncall (dummy1=1016, dummy2=0, dummy3=1016, > dummy4=0xddcad7ac "¨îuÀø\003") at /usr/src/sys/ddb/db_command.c:548 >#2 0xc044bf72 in db_command (last_cmdp=0xc0730300, cmd_table=0x0, > aux_cmd_tablep=0xc06fbd84, aux_cmd_tablep_end=0xc06fbd88) at > /usr/src/sys/ddb/db_command.c:346 >#3 0xc044c0b5 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472 >#4 0xc044f0d5 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:73 >#5 0xc068de7c in kdb_trap (type=12, code=0, regs=0xddcad940) at > /usr/src/sys/i386/i386/db_interface.c:171 >#6 0xc06a40d6 in trap_fatal (frame=0xddcad940, eva=0) at > /usr/src/sys/i386/i386/trap.c:816 >#7 0xc06a3703 in trap (frame= > {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -997562688, tf_esi > = -995818560, tf_ebp = -573908604, tf_isp = -573908628, tf_ebx = > -997562688, tf_edx = -995818560, tf_ecx = 285457664, tf_eax = 285457664, > tf_trapno = 12, tf_err = 0, tf_eip = -1068231411, tf_cs = 8, tf_eflags = > 65538, tf_esp = -996179512, tf_ss = -573908564}) at > /usr/src/sys/i386/i386/trap.c:250 >#8 0xc068f8c8 in calltrap () at {standard input}:94 >#9 0xc054191c in turnstile_wait (ts=0xc48a66c0, lock=0xc49f81c8, > owner=0x0) at /usr/src/sys/kern/subr_turnstile.c:455 >#10 0xc050e205 in _mtx_lock_sleep (m=0xc49f81c8, opts=0, file=0x0, > line=0) at /usr/src/sys/kern/kern_mutex.c:476 >#11 0xc058d115 in if_detach (ifp=0xc49f8008) at /usr/src/sys/net/if.c:592 >#12 0xc0590560 in ether_ifdetach (ifp=0xc49f8008) at > /usr/src/sys/net/if_ethersubr.c:868 >#13 0xc52eea51 in ng_eiface_rmnode () from /boot/kernel/ng_eiface.ko >#14 0xc059a897 in ng_rmnode (node=0xc4d69000, dummy1=0x0, dummy2=0x0, > dummy3=0) at /usr/src/sys/netgraph/ng_base.c:712 >#15 0xc059e44f in ng_generic_msg (here=0xc4d69000, item=0xc4aec300, > lasthook=0x0) at /usr/src/sys/netgraph/ng_base.c:2476 >#16 0xc059e115 in ng_apply_item (node=0xc4d69000, item=0xc4aec300) at > /usr/src/sys/netgraph/ng_base.c:2405 >#17 0xc059db27 in ng_snd_item (item=0xc4aec300, queue=0) at > /usr/src/sys/netgrap >#18 0xc52ea936 in ngc_send () from /boot/kernel/ng_socket.ko >#19 0xc0559b0d in sosend (so=0xc4ab64b0, addr=0xc49fa990, > uio=0xddcadc4c, top=0x >#20 0xc055e48c in kern_sendit (td=0xc4a503c0, s=3, mp=0xddcadcc4, > flags=0, contr >#21 0xc055e2ae in sendit (td=0x0, s=0, mp=0xddcadcc4, flags=0) at > /usr/src/sys/k >#22 0xc055e67b in sendto (td=0x0, uap=0x0) at > /usr/src/sys/kern/uipc_syscalls.c: >#23 0xc06a44c0 in syscall (frame= > {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077941816, tf_esi > = -10779 > 7231, tf_cs = 31, tf_eflags = 514, tf_esp = -1077941892, tf_ss = 47}) at > /usr/sr >#24 0xc068f91d in Xint0x80_syscall () at {standard input}:136 > ---Can't read userspace from dump, or kernel process--- > > (kgdb) l *0xc054150d > 0xc054150d is in turnstile_setowner > (/usr/src/sys/kern/subr_turnstile.c:327). > 322 > 323 mtx_assert(&td_contested_lock, MA_OWNED); > 324 MPASS(owner->td_proc->p_magic == P_MAGIC); > 325 MPASS(ts->ts_owner == NULL); > 326 ts->ts_owner = owner; > 327 LIST_INSERT_HEAD(&owner->td_contested, ts, ts_link); > 328 } > 329 > 330 /* > 331 * Malloc a turnstile for a new thread, initialize it and return it. > -- > > To repeat: > - create an ng_eiface node: > # cat vif.ng > mkpeer . eiface hook ether > name .:hook vif0 > rmhook . hook > # ngctl -f vif.ng > - give the associated ngeth(4) a non-zero MAC address: > # ifconfig ngeth0 link '00:bd:03:11:25:01' > - shutdown the ng_eiface node > # ngctl shutdown vif0: > > I've also tested both 4.9-REL and 5.1-REL, and the panic isn't there. > > Is there anything else of use I can extract from this dump, or anything > else I can do? All pointers welcome. Even simply telling me to file a PR > would be welcome :) > > Obviously I'll fire off a kernel config if that's deemed helpful (it's > essentially GENERIC less devices I don't have, and without > INVARIANTS/WITNESS to allow me to actually get this dump)... > > Thanks, > - Robin > > PS: This message is unicode to allow for non-ASCII characters in the > trace; good thing or bad? > -- > Robin Breathe robin_at_isometry.net +441865741800 > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" -- John Baldwin <jhb_at_FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/Received on Mon Dec 08 2003 - 13:18:35 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:33 UTC