Date: Mon, 08 Dec 2003 22:12:24 +0000 From: Robin Breathe <robin@isometry.net> To: current@freebsd.org Subject: Fatal trap 12: page fault while in kernel mode (subr_turnstile.c) w/ trace Message-ID: <3FD4F748.4050900@isometry.net>
next in thread | raw e-mail | index | archive | help
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 :)
--
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@isometry.net +441865741800
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3FD4F748.4050900>