Fatal trap 12: page fault while in kernel mode
Scott Oertel
freebsd at scottevil.com
Fri Jul 20 19:53:26 UTC 2007
Kai Storbeck wrote:
> Hi all,
>
> Somewhere our IMAP software triggers this panic, and after some
> searching on my part I've found this report: kern/113823
> (http://www.freebsd.org/cgi/query-pr.cgi?pr=113823&cat=kern)
>
> The software I am running is Dovecot serving IMAP to endusers and
> webmail clients.
>
> Perhaps one of the mutex hackers can dive into this problem, I can
> help with more details if needed.
>
>
> Kind regards,
> Kai
>
>
> 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".
>
> Unread portion of the kernel message buffer:
> kernel trap 12 with interrupts disabled
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2; apic id = 06
> fault virtual address = 0x104E
> fault code = supervisor read, page not presentx
> instruction pointer = 0x20:0xc0668f3dp
> stack pointer = 0x28:0xe8916c70e
> frame pointer = 0x28:0xe8916c7cn
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags = resume, IOPL = 0s
> current process = 9 (thread taskq)i
> trap number = 12v
> panic: page faulte
> cpuid = 2
> timeout(9) function: 0xc071a560(0) 0.028705867 s
> Uptime: 2d20h58m42s
> Dumping 3327 MB (2 chunks)
> chunk 0: 1MB (154 pages) ... ok
> chunk 1: 3327MB (851568 pages) 3311 3295 3279 3263 3247 3231 3215
> 3199 3183 3167 3151 3135 3119 3103 3087 3071 3055 3039 3023 3007 2991
> 2975 2959 2943 2927 2911 2895 2879 2863 2847 2831 2815 2799 2783 2767
> 2751 2735 2719 2703 2687 2671 2655 2639 2623 2607 2591 2575 2559 2543
> 2527 2511 2495 2479 2463 2447 2431 2415 2399 2383 2367 2351 2335 2319
> 2303 2287 2271 2255 2239 2223 2207 2191 2175 2159 2143 2127 2111 2095
> 2079 2063 2047 2031 2015 1999 1983 1967 1951 1935 1919 1903 1887 1871
> 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647
> 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423
> 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199
> 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975
> 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703
> 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431
> 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159
> 143 127 111 95 79 63 47 31 15
>
> #0 doadump () at pcpu.h:165
> 165 pcpu.h: No such file or directory.
> in pcpu.h
> (kgdb) bt
> #0 doadump () at pcpu.h:165
> #1 0xc0670918 in boot (howto=260) at ../../../kern/kern_shutdown.c:409
> #2 0xc0670bfa in panic (fmt=0xc08d0a0d "%s")
> at ../../../kern/kern_shutdown.c:565
> #3 0xc087819c in trap_fatal (frame=0xe8916c30, eva=260)
> at ../../../i386/i386/trap.c:837
> #4 0xc087794a in trap (frame=
> {tf_fs = -393150456, tf_es = -1064959960, tf_ds = -393150424,
> tf_edi = -935090688, tf_esi = -900488032, tf_ebp = -393122692, tf_isp
> = -393122724, tf_ebx = 4, tf_edx = 6, tf_ecx = 2, tf_eax = 1,
> tf_trapno = 12, tf_err = 0, tf_eip = -1067020483, tf_cs = 32,
> tf_eflags = 65538, tf_esp = 1714, tf_ss = -1064340051})
> at ../../../i386/i386/trap.c:270
> #5 0xc08649ea in calltrap () at ../../../i386/i386/exception.s:139
> #6 0xc0668f3d in _mtx_lock_sleep (m=0xca53a4a0, tid=3359876608, opts=0,
> file=0xc08f75ad "../../../kern/uipc_usrreq.c", line=1714)
> at ../../../kern/kern_mutex.c:546
> #7 0xc0668b93 in _mtx_lock_flags (m=0x2, opts=0,
> file=0xc08f75ad "../../../kern/uipc_usrreq.c", line=1714)
> at ../../../kern/kern_mutex.c:288
> #8 0xc06b204b in unp_gc (arg=0x0, pending=1)
> at ../../../kern/uipc_usrreq.c:1714
> #9 0xc068f7c0 in taskqueue_run (queue=0xc843ca80)
> at ../../../kern/subr_taskqueue.c:257
> #10 0xc068fb3e in taskqueue_thread_loop (arg=0x1)
> at ../../../kern/subr_taskqueue.c:376
> #11 0xc065d184 in fork_exit (callout=0xc068faf4 <taskqueue_thread_loop>,
> arg=0xc09df4e8, frame=0xe8916d38) at ../../../kern/kern_fork.c:821
> #12 0xc0864a4c in fork_trampoline () at
> ../../../i386/i386/exception.s:208
> (kgdb)
>
I was getting this exact panic pretty much every week, I had 6.2-RELEASE
installed on about 10 machines. The one machine which was getting the
panic most often I upgraded to 6.2-STABLE on 'Mon Apr 2 13:53:14 PDT
2007' and it's been up for 108 days now without any issues. I've
submited this time and time again to the mailing lists and never found a
real answer, finally I just resorted to trying this 6.2-STABLE, now
since last month I updated the other 9 machines and haven't had this
panic at all.
Here is one of the original threads I started regarding this issue:
http://monkey.org/freebsd/archive/freebsd-hackers/200703/msg00127.html
Cheers,
Scott Oertel
More information about the freebsd-stable
mailing list