Date: Fri, 20 Jul 2007 14:16:12 -0500 From: Scott Oertel <freebsd@scottevil.com> To: Kai Storbeck <kai@xs4all.nl> Cc: freebsd-stable@freebsd.org Subject: Re: Fatal trap 12: page fault while in kernel mode Message-ID: <46A109FC.20009@scottevil.com> In-Reply-To: <469CB87D.6030901@xs4all.nl> References: <20070411105332.GC7847@xs4all.nl> <20070419123329.GA10189@xs4all.nl> <20070423153547.GD20155@xs4all.nl> <20070423155552.GB1006@xor.obsecurity.org> <20070423170526.GA83776@xs4all.nl> <20070423172230.GA92248@xor.obsecurity.org> <20070514122632.GD2093@xs4all.nl> <20070612091459.GF56421@xs4all.nl> <20070613035200.GB26190@rot13.obsecurity.org> <469CB87D.6030901@xs4all.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46A109FC.20009>