Date: Sun, 25 Dec 2005 03:00:44 -0800 (PST) From: kamal kc <kamal_ckk@yahoo.com> To: freebsd <freebsd-hackers@freebsd.org> Subject: Fatal trap 12: page fault while in kernel mode Message-ID: <20051225110044.13099.qmail@web35707.mail.mud.yahoo.com>
next in thread | raw e-mail | index | archive | help
hello everybody,
i am recently troubled by kernel panics that occur as
soon as
i run my modified kernel. the only modification i have
done
is i have added compression/decompression function in
the
bridge.c file. I am running 5.4 RELEASE.
i am just a new beginner in programming the kernel and
may
have insufficient knowledge regarding it.
things i have done in the function that could affect
the kernel operation are:
1. i frequently allocate memory using malloc() in
M_DEVBUF and
M_TEMP with M_WAITOK flag
2. i allocate memory with malloc and construct tree.
the node count
can go up 350 so that i may call malloc about 600
times in the
routine. i know that may sound pretty dumb but
right now i have
no other choice now as i know so little.
3. the functions are pretty longer and contain loops
so they may consume time
since the bridge code may be called for all the
packets flowing
through the network.
4. i have used data structures like linked lists and
trees.
now the problem is as soon as i run my modified kernel
it panics with
fatal trap 12. the name of the process that crashed is
sometimes the cron,
sometimes ps, sometimes top, sometimes g_up, and
sometimes sendmail.
i don't know what to do because the i have tested the
function
separately and it works fine. i used the dmalloc to
see whether
the memory leak was present but i didnot find any. it
may be
posible that my tests with dmalloc were insufficient.
So i have put the crash dumps here that may help
some of you suggest me whether there is anything i
can possibly do in order to solve this panic.
Is the problem related to memory leaks or sleeping
on mutexes or some other causes.
i have added my function just before the
IFQ_HANDOFF().
thanks,
kamal kc
--------------------
Panic message:-->
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
fault virtual address=0x6c
fault code =supervisor read, page not present
instruction pointer=0x8:0xc052eafd
stack pointer=0x10:0xd50349d0
frame pointer=0x10:0xd50349d4
code segment=base 0x0, limit 0xfffff, type 0x1b
=DPL 0, pres 1, def32 1, gran 1
processor eflags=resume, IOPL=0
current process=462 (sendmail)
trap number=12
panic: page fault
decomp# kgdb kernel.debug /var/crash/vmcore.2
[GDB will not be able to debug user-mode threads:
/usr/lib/libthread_db.so: Undefined symbol
"ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General
Public License, and you are
welcome to change it and/or distribute copies of it
under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show
warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
#0 doadump () at pcpu.h:159
159 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) bt
#0 doadump () at pcpu.h:159
#1 0xc0510d86 in boot (howto=260) at
../../../kern/kern_shutdown.c:410
#2 0xc051101c in panic (fmt=0xc06b9b28 "%s")
at ../../../kern/kern_shutdown.c:566
#3 0xc0692820 in trap_fatal (frame=0xd5034990,
eva=108)
at ../../../i386/i386/trap.c:817
#4 0xc069200d in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 2,
tf_esi = -1049545216, tf_ebp = -721204780, tf_isp =
-721204804, tf_ebx = -1050635136, tf_edx =
-1050635136, tf_ecx = 0, tf_eax = -1049545184,
tf_trapno = 12, tf_err = 0, tf_eip = -1068307715,
tf_cs = 8, tf_eflags = 65539, tf_esp = -1049545216,
tf_ss = -721204748}) at ../../../i386/i386/trap.c:255
#5 0xc0682cda in calltrap () at
../../../i386/i386/exception.s:140
#6 0x00000018 in ?? ()
#7 0x00000010 in ?? ()
#8 0x00000010 in ?? ()
#9 0x00000002 in ?? ()
#10 0xc1713600 in ?? ()
#11 0xd50349d4 in ?? ()
#12 0xd50349bc in ?? ()
#13 0xc1609480 in ?? ()
#14 0xc1609480 in ?? ()
#15 0x00000000 in ?? ()
#16 0xc1713620 in ?? ()
---Type <return> to continue, or q <return> to quit---
#17 0x0000000c in ?? ()
#18 0x00000000 in ?? ()
#19 0xc052eafd in turnstile_setowner (ts=0xc1609480,
owner=0x0)
at ../../../kern/subr_turnstile.c:367
#20 0xc052edbf in turnstile_wait (ts=0xc1609480,
lock=0xc16ba800, owner=0x0)
at ../../../kern/subr_turnstile.c:504
#21 0xc0508769 in _mtx_lock_sleep (m=0xc16ba800,
td=0xc1713600, opts=0,
file=0x0, line=0) at
../../../kern/kern_mutex.c:552
#22 0xc063c691 in ufsdirhash_lookup (ip=0xc170d1a4,
name=0xc16dd009 "nss_compat.so.1", namelen=15,
offp=0x0, bpp=0x0,
prevoffp=0x0) at
../../../ufs/ufs/ufs_dirhash.c:349
#23 0xc063e612 in ufs_lookup (ap=0xd5034b78)
at ../../../ufs/ufs/ufs_lookup.c:214
#24 0xc0645623 in ufs_vnoperate (ap=0x0) at
../../../ufs/ufs/ufs_vnops.c:2821
#25 0xc0558402 in vfs_cache_lookup (ap=0x0) at
vnode_if.h:82
#26 0xc0645623 in ufs_vnoperate (ap=0x0) at
../../../ufs/ufs/ufs_vnops.c:2821
#27 0xc055d5cb in lookup (ndp=0xd5034c78) at
vnode_if.h:52
#28 0xc055d069 in namei (ndp=0xd5034c78) at
../../../kern/vfs_lookup.c:181
#29 0xc0569792 in kern_access (td=0xc1713600,
path=0x0,
pathseg=UIO_USERSPACE, flags=0) at
../../../kern/vfs_syscalls.c:1839
#30 0xc0569735 in access (td=0xc1713600, uap=0x0)
at ../../../kern/vfs_syscalls.c:1817
#31 0xc0692b2b in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi =
-1077950048, tf_esi = 67212---Type <return> to
continue, or q <return> to quit---
9024, tf_ebp = -1077950120, tf_isp = -721203852,
tf_ebx = 672089560, tf_edx = -1077949824, tf_ecx =
672129049, tf_eax = 33, tf_trapno = 12, tf_err = 2,
tf_eip = 672000727, tf_cs = 31, tf_eflags = 642,
tf_esp = -1077950164, tf_ss = 47})
at ../../../i386/i386/trap.c:1009
#32 0xc0682d2f in Xint0x80_syscall () at
../../../i386/i386/exception.s:201
#33 0x0000002f in ?? ()
#34 0x0000002f in ?? ()
#35 0x0000002f in ?? ()
#36 0xbfbfc9a0 in ?? ()
#37 0x280fe000 in ?? ()
#38 0xbfbfc958 in ?? ()
#39 0xd5034d74 in ?? ()
#40 0x280f45d8 in ?? ()
#41 0xbfbfca80 in ?? ()
#42 0x280fe019 in ?? ()
#43 0x00000021 in ?? ()
#44 0x0000000c in ?? ()
#45 0x00000002 in ?? ()
#46 0x280dead7 in ?? ()
#47 0x0000001f in ?? ()
#48 0x00000282 in ?? ()
#49 0xbfbfc92c in ?? ()
#50 0x0000002f in ?? ()
#51 0x00000000 in ?? ()
---Type <return> to continue, or q <return> to quit---
#52 0x00000000 in ?? ()
#53 0x00000000 in ?? ()
#54 0x00000000 in ?? ()
#55 0x0995c000 in ?? ()
#56 0xc1712e20 in ?? ()
#57 0xc1713600 in ?? ()
#58 0xd5034a30 in ?? ()
#59 0xd5034a18 in ?? ()
#60 0xc14f9180 in ?? ()
#61 0xc0520947 in sched_switch (td=0x280fe000,
newtd=0x280f45d8, flags=Cannot access memory at
address 0xbfbfc968
)
at ../../../kern/sched_4bsd.c:881
Previous frame inner to this frame (corrupt stack?)
(kgdb) up 19
#19 0xc052eafd in turnstile_setowner (ts=0xc1609480,
owner=0x0)
at ../../../kern/subr_turnstile.c:367
367 ts->ts_owner = owner;
(kgdb) list
362 {
363
364 mtx_assert(&td_contested_lock, MA_OWNED);
365 MPASS(owner->td_proc->p_magic == P_MAGIC);
366 MPASS(ts->ts_owner == NULL);
367 ts->ts_owner = owner;
368 LIST_INSERT_HEAD(&owner->td_contested, ts,
ts_link);
369 }
370
371 /*
(kgdb) print ts
$1 = (struct turnstile *) 0xc1609480
(kgdb) quit
decomp#
__________________________________
Yahoo! for Good - Make a difference this year.
http://brand.yahoo.com/cybergivingweek2005/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051225110044.13099.qmail>