panic: Fatal trap 12: page fault while in kernel mode (current process = 4254 (perl5.8.8))
Hi,
I experienced lots of kernel panic after I installed openwebmail on my
mail server.
The environment is :
[Mail Server] <=> [Mail Spool Server]
nfs
Mail Server: 6.1-RELEASE (panic 3 times a day)
Mail Spool Server: 6.0-RELEASE
I also installed www/apache20, mail/postfix.
The mount options is rw, quota (Yes, I used quota)
I have tried to replace my kernel, but GENERIC and custom kernels panic, too.
Please give me some advice :)
==
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x34
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc050f162
stack pointer = 0x28:0xd12519b8
frame pointer = 0x28:0xd12519c4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 4254 (perl5.8.8)
trap number = 12
panic: page fault
KDB: stack backtrace:
kdb_backtrace(100,c24b4600,28,d1251978,c) at kdb_backtrace+0x29
panic(c0620009,c06413f8,0,f,c24aea9b) at panic+0xa8
trap_fatal(d1251978,34,c24b4600,c2330ce4,c) at trap_fatal+0x2a6
trap_pfault(d1251978,0,34) at trap_pfault+0x1d3
trap(d1250008,d1250028,c2060028,c708afb8,c708afb8) at trap+0x2fd
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0xc050f162, esp = 0xd12519b8, ebp = 0xd12519c4 ---
vfs_vmio_release(c708afb8) at vfs_vmio_release+0x12
getnewbuf(0,0,8000,8000,c8000) at getnewbuf+0x2b0
getblk(c29b4770,19,0,8000,0) at getblk+0x35c
nfs_getcacheblk(19,0,8000,c24b4600,8000) at nfs_getcacheblk+0x81
nfs_bioread(c29b4770,d1251cbc,2f,c2353b00,d1251bcc) at nfs_bioread+0x983
nfs_read(d1251bf4) at nfs_read+0x33
VOP_READ_APV(c2084d20,d1251bf4) at VOP_READ_APV+0x38
vn_read(c224fea0,d1251cbc,c2353b00,0,c24b4600) at vn_read+0x196
dofileread(c24b4600,3,c224fea0,d1251cbc,) at dofileread+0x85
kern_readv(c24b4600,3,d1251cbc,9013000,1000) at kern_readv+0x36
read(c24b4600,d1251d04,3,27,202) at read+0x45
syscall(c05f003b,3b,3b,806c200,3) at syscall+0x2b7
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (3, FreeBSD ELF32, read), eip = 0x282637df, esp =
0xbfbfe28c, ebp = 0xbfbfe2c8 ---
Uptime: 14h32m59s
Dumping 255 MB (2 chunks)
chunk 0: 1MB (160 pages) ... ok
chunk 1: 255MB (65280 pages) 240 224 208 192 176 160 144 128 112 96
80 64 48 32 16
#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 0xc04c8cfd in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:402
#2 0xc04c8fc4 in panic (fmt=0xc0620009 "%s") at
/usr/src/sys/kern/kern_shutdown.c:558
#3 0xc06028b6 in trap_fatal (frame=0xd1251978, eva=52) at
/usr/src/sys/i386/i386/trap.c:836
#4 0xc06025e7 in trap_pfault (frame=0xd1251978, usermode=0, eva=52)
at /usr/src/sys/i386/i386/trap.c:744
#5 0xc0602201 in trap (frame=
{tf_fs = -786104312, tf_es = -786104280, tf_ds = -1039794136,
tf_edi = -955732040, tf_esi = -955732040, tf_ebp = -786097724, tf_isp
= -786097756, tf_ebx = -955732040, tf_edx = 4, tf_ecx = -1035254272,
tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1068437150, tf_cs =
32, tf_eflags = 590338, tf_esp = -955732040, tf_ss = -955732040}) at
/usr/src/sys/i386/i386/trap.c:434
#6 0xc05f1c5a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc050f162 in vfs_vmio_release (bp=0xc708afb8) at atomic.h:146
#8 0xc050f974 in getnewbuf (slpflag=0, slptimeo=0, size=32768, maxsize=32768)
at /usr/src/sys/kern/vfs_bio.c:1779
#9 0xc0510eb0 in getblk (vp=0xc29b4770, blkno=25, size=32768,
slpflag=0, slptimeo=0, flags=0)
at /usr/src/sys/kern/vfs_bio.c:2486
#10 0xc206631d in ?? ()
#11 0xc29b4770 in ?? ()
#12 0x0019 in ?? ()
#13 0x in ?? ()
#14 0x8000 in ?? ()
#15 0x in ?? ()
#16 0x in ?? ()
#17 0x in ?? ()
#18 0x in ?? ()
#19 0xc7025860 in ?? ()
#20 0xc29b4830 in ?? ()
#21 0x in ?? ()
#22 0xc1e28400 in ?? ()
#23 0xd1251a94 in ?? ()
#24 0xc05106dc in incore (bo=0x19, blkno=140737488355328) at
/usr/src/sys/kern/vfs_bio.c:2141
#25 0xc20685ff in ?? ()
#26 0x0019 in ?? ()
#27 0x in ?? ()
#28 0x8000 in ?? ()
#29 0xc24b4600 in ?? ()
#30 0x8000 in ?? ()
#31 0x1dba5906 in ?? ()
#32 0x in ?? ()
#33 0x8853088c in ?? ()
#34 0x0019 in ?? ()
#35 0x in ?? ()
#36 0x004ba000 in ?? ()
#37 0x in ?? ()
#38 0x8000 in ?? ()
#39 0x in ?? ()
#40 0x000c8000 in ?? ()
#41 0x in ?? ()
#42 0x in ?? ()
#43 0x in ?? ()
#44 0x in ?? ()
#45 0x in ?? ()
#46 0x005e in ?? ()
#47 0x8000 in ?? ()
#48 0x0018 in ?? ()
#49 0x in ?? ()
#50 0xc24295a0 in ?? ()
#51 0xc24b4600 in ?? ()
#52 0x in ?? ()
#53 0x8000 in ?? ()
#54 0xc22e58fc in ?? ()
#55 0xc0674d80 in vop_getattr_vp_offsets ()
#56 0xc29b4770 in ?? ()
#57 0xd1251b2c in ?? ()
#58 0xc2353b00 in ?? ()
#59 0xc24b4600 in ?? ()
#60 0xc24b4600 in ?? ()
#
panic: Fatal trap 12: page fault while in kernel mode (current process = 4254 (perl5.8.8))
Hi,
I experienced lots of kernel panic after I installed openwebmail on my
mail server.
The environment is :
[Mail Server] <=> [Mail Spool Server]
nfs
Mail Server: 6.1-RELEASE (panic 3 times a day)
Mail Spool Server: 6.0-RELEASE
I also installed www/apache20, mail/postfix.
The mount options is rw, quota (Yes, I used quota)
I have tried to replace my kernel, but GENERIC and custom kernels panic, too.
Please give me some advice :)
==
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x34
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc050f162
stack pointer = 0x28:0xd12519b8
frame pointer = 0x28:0xd12519c4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 4254 (perl5.8.8)
trap number = 12
panic: page fault
KDB: stack backtrace:
kdb_backtrace(100,c24b4600,28,d1251978,c) at kdb_backtrace+0x29
panic(c0620009,c06413f8,0,f,c24aea9b) at panic+0xa8
trap_fatal(d1251978,34,c24b4600,c2330ce4,c) at trap_fatal+0x2a6
trap_pfault(d1251978,0,34) at trap_pfault+0x1d3
trap(d1250008,d1250028,c2060028,c708afb8,c708afb8) at trap+0x2fd
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0xc050f162, esp = 0xd12519b8, ebp = 0xd12519c4 ---
vfs_vmio_release(c708afb8) at vfs_vmio_release+0x12
getnewbuf(0,0,8000,8000,c8000) at getnewbuf+0x2b0
getblk(c29b4770,19,0,8000,0) at getblk+0x35c
nfs_getcacheblk(19,0,8000,c24b4600,8000) at nfs_getcacheblk+0x81
nfs_bioread(c29b4770,d1251cbc,2f,c2353b00,d1251bcc) at nfs_bioread+0x983
nfs_read(d1251bf4) at nfs_read+0x33
VOP_READ_APV(c2084d20,d1251bf4) at VOP_READ_APV+0x38
vn_read(c224fea0,d1251cbc,c2353b00,0,c24b4600) at vn_read+0x196
dofileread(c24b4600,3,c224fea0,d1251cbc,) at dofileread+0x85
kern_readv(c24b4600,3,d1251cbc,9013000,1000) at kern_readv+0x36
read(c24b4600,d1251d04,3,27,202) at read+0x45
syscall(c05f003b,3b,3b,806c200,3) at syscall+0x2b7
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (3, FreeBSD ELF32, read), eip = 0x282637df, esp =
0xbfbfe28c, ebp = 0xbfbfe2c8 ---
Uptime: 14h32m59s
Dumping 255 MB (2 chunks)
chunk 0: 1MB (160 pages) ... ok
chunk 1: 255MB (65280 pages) 240 224 208 192 176 160 144 128 112 96
80 64 48 32 16
#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 0xc04c8cfd in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:402
#2 0xc04c8fc4 in panic (fmt=0xc0620009 "%s") at
/usr/src/sys/kern/kern_shutdown.c:558
#3 0xc06028b6 in trap_fatal (frame=0xd1251978, eva=52) at
/usr/src/sys/i386/i386/trap.c:836
#4 0xc06025e7 in trap_pfault (frame=0xd1251978, usermode=0, eva=52)
at /usr/src/sys/i386/i386/trap.c:744
#5 0xc0602201 in trap (frame=
{tf_fs = -786104312, tf_es = -786104280, tf_ds = -1039794136,
tf_edi = -955732040, tf_esi = -955732040, tf_ebp = -786097724, tf_isp
= -786097756, tf_ebx = -955732040, tf_edx = 4, tf_ecx = -1035254272,
tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1068437150, tf_cs =
32, tf_eflags = 590338, tf_esp = -955732040, tf_ss = -955732040}) at
/usr/src/sys/i386/i386/trap.c:434
#6 0xc05f1c5a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc050f162 in vfs_vmio_release (bp=0xc708afb8) at atomic.h:146
#8 0xc050f974 in getnewbuf (slpflag=0, slptimeo=0, size=32768, maxsize=32768)
at /usr/src/sys/kern/vfs_bio.c:1779
#9 0xc0510eb0 in getblk (vp=0xc29b4770, blkno=25, size=32768,
slpflag=0, slptimeo=0, flags=0)
at /usr/src/sys/kern/vfs_bio.c:2486
#10 0xc206631d in ?? ()
#11 0xc29b4770 in ?? ()
#12 0x0019 in ?? ()
#13 0x in ?? ()
#14 0x8000 in ?? ()
#15 0x in ?? ()
#16 0x in ?? ()
#17 0x in ?? ()
#18 0x in ?? ()
#19 0xc7025860 in ?? ()
#20 0xc29b4830 in ?? ()
#21 0x in ?? ()
#22 0xc1e28400 in ?? ()
#23 0xd1251a94 in ?? ()
#24 0xc05106dc in incore (bo=0x19, blkno=140737488355328) at
/usr/src/sys/kern/vfs_bio.c:2141
#25 0xc20685ff in ?? ()
#26 0x0019 in ?? ()
#27 0x in ?? ()
#28 0x8000 in ?? ()
#29 0xc24b4600 in ?? ()
#30 0x8000 in ?? ()
#31 0x1dba5906 in ?? ()
#32 0x in ?? ()
#33 0x8853088c in ?? ()
#34 0x0019 in ?? ()
#35 0x in ?? ()
#36 0x004ba000 in ?? ()
#37 0x in ?? ()
#38 0x8000 in ?? ()
#39 0x in ?? ()
#40 0x000c8000 in ?? ()
#41 0x in ?? ()
#42 0x in ?? ()
#43 0x in ?? ()
#44 0x in ?? ()
#45 0x in ?? ()
#46 0x005e in ?? ()
#47 0x8000 in ?? ()
#48 0x0018 in ?? ()
#49 0x in ?? ()
#50 0xc24295a0 in ?? ()
#51 0xc24b4600 in ?? ()
#52 0x in ?? ()
#53 0x8000 in ?? ()
#54 0xc22e58fc in ?? ()
#55 0xc0674d80 in vop_getattr_vp_offsets ()
#56 0xc29b4770 in ?? ()
#57 0xd1251b2c in ?? ()
#58 0xc2353b00 in ?? ()
#59 0xc24b4600 in ?? ()
#60 0xc24b4600 in ?? ()
#
Re[2]: [panic] Fatal trap 12: page fault while in kernel mode
Hello Peter, Friday, February 10, 2006, 7:10:50 PM, you has on mind: > Please don't cross-post. A problem with 6-RELEASE is not appropriate > for [EMAIL PROTECTED] I apologize. > On Fri, 2006-Feb-10 14:48:39 +0100, Daniel Gerzo wrote: >> I've just got installed a brand new box, and I can say that it's >> hanging on regular basis, around every 10 minutes. > Is the panic always at the same place or does it move around? __qdivrem() > hasn't been touched for just under two years and it seems unlikely that > it would suddenly start triggering panics. yes. the bactrace is the same all the time. > Since you mention that this is a brand new box, are you certain that it > isn't a hardware fault? I suggest running (eg) memtest86 on it for a > few hours and see if that picks anything up. we upgraded our power supply to the stronger one and we can get 1+ hours of uptime before crash. I've run sysutils/memtest and it didn't fail in any way. I can provide more info if anybody tell me how :-) -- Best regards Daniel Gerzo ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [panic] Fatal trap 12: page fault while in kernel mode
Please don't cross-post. A problem with 6-RELEASE is not appropriate for [EMAIL PROTECTED] On Fri, 2006-Feb-10 14:48:39 +0100, Daniel Gerzo wrote: > I've just got installed a brand new box, and I can say that it's > hanging on regular basis, around every 10 minutes. Is the panic always at the same place or does it move around? __qdivrem() hasn't been touched for just under two years and it seems unlikely that it would suddenly start triggering panics. Since you mention that this is a brand new box, are you certain that it isn't a hardware fault? I suggest running (eg) memtest86 on it for a few hours and see if that picks anything up. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[panic] Fatal trap 12: page fault while in kernel mode
Hello,
I've just got installed a brand new box, and I can say that it's
hanging on regular basis, around every 10 minutes.
The backtrace is included, as well as the dmesg.
Any help with this will be appreciated.
Thank you.
--
Sincerely,
Daniel Gerzo
bigbang# kgdb kernel.debug /var/crash/vmcore.0
[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".
Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xa9b2d30c
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc0810407
stack pointer = 0x28:0xe33b9b58
frame pointer = 0x28:0xe33b9be0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 11 (idle)
trap number = 12
panic: page fault
Uptime: 17m32s
Dumping 1007 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 1007MB (257776 pages) 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) list *0xc0810407
0xc0810407 is in __qdivrem (/usr/src/sys/libkern/qdivrem.c:251).
246 u[i + j] = LHALF(t);
247 t = HHALF(t);
248 }
249 u[j] = LHALF(u[j] + t);
250 }
251 q[j] = qhat;
252 } while (++j <= m); /* D7: loop on j. */
253
254 /*
255 * If caller wants the remainder, we have to calculate it as
(kgdb) backtrace
#0 doadump () at pcpu.h:165
#1 0xc0638202 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399
#2 0xc0638498 in panic (fmt=0xc084e5a2 "%s") at
/usr/src/sys/kern/kern_shutdown.c:555
#3 0xc0807c30 in trap_fatal (frame=0xe33b9b18, eva=2847068940) at
/usr/src/sys/i386/i386/trap.c:831
#4 0xc08073d2 in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 606, tf_esi = 0, tf_ebp =
-482632736, tf_isp = -482632892, tf_ebx = 0, tf_edx = 0, tf_ecx = -1447898356,
tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip = -1065286649, tf_cs = 32,
tf_eflags = 589894, tf_esp = 55296, tf_ss = 55930})
at /usr/src/sys/i386/i386/trap.c:267
#5 0xc07f6dca in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#6 0xc0810407 in __qdivrem (uq=Unhandled dwarf expression opcode 0x93
) at /usr/src/sys/libkern/qdivrem.c:251
#7 0xc081050e in __udivdi3 (a=9223372036854775808, b=3579545) at
/usr/src/sys/libkern/udivdi3.c:47
#8 0xc0640e5d in tc_windup () at /usr/src/sys/kern/kern_tc.c:491
#9 0xc064132d in tc_ticktock () at /usr/src/sys/kern/kern_tc.c:756
#10 0xc060ec50 in hardclock (frame=0xe33b9c98) at
/usr/src/sys/kern/kern_clock.c:243
#11 0xc07fcbe5 in lapic_handle_timer (frame=
{cf_vec = 0, cf_fs = -1037828088, cf_es = -1067319256, cf_ds = 40, cf_edi
= -1036617472, cf_esi = -1036617448, cf_ebp = -482632484, cf_ebx = 0, cf_edx =
0, cf_ecx = 1000, cf_eax = 1000, cf_eip = -1062831147, cf_cs = 32, cf_eflags =
524870, cf_esp = -482632452, cf_ss = -1062848970}) at
/usr/src/sys/i386/i386/local_apic.c:630
#12 0xc07f73b0 in Xtimerint () at apic_vector.s:137
#13 0xc0a67bd5 in ?? ()
#14 0xe33b9d04 in ?? ()
#15 0xc07fe487 in cpu_idle () at /usr/src/sys/i386/i386/machdep.c:1134
Previous frame inner to this frame (corrupt stack?)
(kgdb) list
256 * u[m..m+n] >> d (this is at most n digits and thus fits in
257 * u[m+1..m+n], but we may need more source digits).
258 */
259 if (arq) {
260 if (d) {
261 for (i = m + n; i > m; --i)
262 u[i] = (u[i] >> d) |
263 LHALF(u[i - 1] << (HALF_BITS - d));
264 u[i] = 0;
265 }
(kgdb) backtrace full
#0 doadump () at pcpu.h:165
No locals.
#1 0xc0638202 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399
first_buf_printf = 1
#2 0xc0638498 in panic (fmt=0xc084e5a2 "%s") at
/usr/src/sys/kern/kern_shutdown.c:555
td = (struct thread *) 0xc2247780
boo
Re: graid3 + rsync + 5.4-STABLE repeatable panic (Fatal trap 12: page fault while in kernel mode)
On Wednesday 29 June 2005 16:42, Dominic Marks wrote: > Hello, > > I'm trying to use graid3 to create a raid volume from three > 250GB SATA discs. I can successfully label, format, and mount > the disc. The problem arises when I try and migrate some data > on to the new volume. I'm using rsync to do this from over the > local network, unfortunately this seems to be produce an > immediate and reproduceable panic (hand copied): > > Fatal trap 12: page fault while in kernel mode > > fault virtual address = 0xc30f8000 > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc05e9783 > stack pointer = 0x10:0xd8030c38 > frame pointer = 0x10:0xd8030c80 > code segment = base 0x0, limit 0xf type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 617 (g_raid3 raid) > trap number = 12 > panic: page fault Having recompiled I can no longer produce the panic. I think I may have caused it myself, I had forgotten that I had been tinkering with some values in sys/sys/param.h last week, but it didn't ring a bell when the system went down. I'd been running with MAXPHYS and DFLTPHYS at 256 and it seems graid3 does not like one of those paramters being raised, I suspect its DFLTPHYS and that perhaps graid3 depends on its value for some calculations. This is pure speculation. My apologies for the incorrect report. > Other programs (touch, ls, diskinfo, etc) do not seem to provoke > the panic, but rsync will kill the system within a second. > > I got a dump (once), but I think it is corrupt in some way > because I have not been able to get a backtrace or any other > useful data from it. > > # kgdb kernel.debug /usr/crash/vmcore.0 > kgdb: kvm_read: invalid address (f9) > > (This line is printed again, and again, and again ...) > > This may be because I compiled my debugging kernel after I had > installed the system, although it should have been an identical > source tree ... I'm currently rebuilding the system to > the freshest available -STABLE in the hope that may give a > full backtrace. > > FreeBSD mrt.helenmarks.co.uk 5.4-STABLE FreeBSD 5.4-STABLE #0 > Mon Jun 27 09:34:02 BST 2005 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DEV i386 > > The only thing slightly odd about the machine is that each > disc is one its own SATA controller. One disc is attached to an > Intel ICH6 the other two are attached two Silicon Image (3112) > based cards. The root device is ad2, since the additional cards > have pushed themselves to the front. This is a temporary setup > to facilitate migration of data from system to system. > > If I can do anything to help track the problem down, please say. > I really want this to work, and I have some time in which to run > tests. > > * A side note, I have noticed that the panic is often accompanied by > a ATA DMA timeout (ad1). Could this cause the panic to occur? > > Copyright (c) 1992-2005 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, > 1994 The Regents of the University of California. All rights > reserved. FreeBSD 5.4-STABLE #0: Mon Jun 27 09:34:02 BST 2005 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DEV > WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant > WARNING: MPSAFE network stack disabled, expect reduced performance. > ACPI APIC Table: > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Celeron(R) CPU 2.53GHz (2527.01-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 > > Features=0xbfebfbffPGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PB >E> real memory = 526958592 (502 MB) > avail memory = 509628416 (486 MB) > ioapic0: Changing APIC ID to 8 > ioapic0 irqs 0-23 on motherboard > lapic0: Forcing LINT1 to edge trigger > npx0: on motherboard > npx0: INT 16 interface > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > cpu0: on acpi0 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: irq 16 at device 1.0 on pci0 > pci1: on pcib1 > pci0: at device 2.0 (no driver attached) > pcib2: irq 16 at device 28.0 on pci0 > pci2: on pcib2 > bge0: mem > 0xdfdf-0xdfdf irq 16 at device 0.0 on pci2 > miibus0: on bge0 > brgphy0: on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > 1000baseTX-FDX, auto > bge0: Ethernet address: 00:11:11:c3:2c:91 > pcib3: irq 17 at device 28.1 on pci0 > pci3: on pcib3 > pci0: at device 29.0 (no driver attached) > pci0: at device 29.1 (no driver attached) > pci0: at device 29.2 (no driver attached) > pci0: at device 29.3 (no driver attached) > pci0: at device 29.7 (no driver attached) > pcib4: at device 30.0 on pci0 > pci4: on pcib4 > atapci0: port > 0xdce0-0xdcef,0xdcb4-0xdcb7,0xdcc8-0xdccf,0xdcb0-0xdcb3,0xdcc0-0xdcc7 > mem 0xdfaffc0
Re: graid3 + rsync + 5.4-STABLE repeatable panic (Fatal trap 12: page fault while in kernel mode)
On Wednesday 29 June 2005 18:14, Kris Kennaway wrote: > On Wed, Jun 29, 2005 at 04:42:49PM +0100, Dominic Marks wrote: > > This may be because I compiled my debugging kernel after I had > > installed the system, although it should have been an identical > > source tree ... I'm currently rebuilding the system to > > the freshest available -STABLE in the hope that may give a > > full backtrace. > > Yes, you can have this kind of problem if you compile a kernel.debug > "after the fact" and it doesn't quite match. Good to know, thank you. I've just built a fresh -stable system, so I will attempt to get the panic again with some useful information this time. > Kris Cheers, -- Dominic GoodforBusiness.co.uk I.T. Services for SMEs in the UK. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: graid3 + rsync + 5.4-STABLE repeatable panic (Fatal trap 12: page fault while in kernel mode)
On Wed, Jun 29, 2005 at 04:42:49PM +0100, Dominic Marks wrote: > This may be because I compiled my debugging kernel after I had > installed the system, although it should have been an identical > source tree ... I'm currently rebuilding the system to > the freshest available -STABLE in the hope that may give a > full backtrace. Yes, you can have this kind of problem if you compile a kernel.debug "after the fact" and it doesn't quite match. Kris pgpOEvifiGsMv.pgp Description: PGP signature
graid3 + rsync + 5.4-STABLE repeatable panic (Fatal trap 12: page fault while in kernel mode)
Hello, I'm trying to use graid3 to create a raid volume from three 250GB SATA discs. I can successfully label, format, and mount the disc. The problem arises when I try and migrate some data on to the new volume. I'm using rsync to do this from over the local network, unfortunately this seems to be produce an immediate and reproduceable panic (hand copied): Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc30f8000 fault code = supervisor write, page not present instruction pointer = 0x8:0xc05e9783 stack pointer = 0x10:0xd8030c38 frame pointer = 0x10:0xd8030c80 code segment = base 0x0, limit 0xf type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 617 (g_raid3 raid) trap number = 12 panic: page fault Other programs (touch, ls, diskinfo, etc) do not seem to provoke the panic, but rsync will kill the system within a second. I got a dump (once), but I think it is corrupt in some way because I have not been able to get a backtrace or any other useful data from it. # kgdb kernel.debug /usr/crash/vmcore.0 kgdb: kvm_read: invalid address (f9) (This line is printed again, and again, and again ...) This may be because I compiled my debugging kernel after I had installed the system, although it should have been an identical source tree ... I'm currently rebuilding the system to the freshest available -STABLE in the hope that may give a full backtrace. FreeBSD mrt.helenmarks.co.uk 5.4-STABLE FreeBSD 5.4-STABLE #0 Mon Jun 27 09:34:02 BST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DEV i386 The only thing slightly odd about the machine is that each disc is one its own SATA controller. One disc is attached to an Intel ICH6 the other two are attached two Silicon Image (3112) based cards. The root device is ad2, since the additional cards have pushed themselves to the front. This is a temporary setup to facilitate migration of data from system to system. If I can do anything to help track the problem down, please say. I really want this to work, and I have some time in which to run tests. * A side note, I have noticed that the panic is often accompanied by a ATA DMA timeout (ad1). Could this cause the panic to occur? Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-STABLE #0: Mon Jun 27 09:34:02 BST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DEV WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant WARNING: MPSAFE network stack disabled, expect reduced performance. ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) CPU 2.53GHz (2527.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Features=0xbfebfbff real memory = 526958592 (502 MB) avail memory = 509628416 (486 MB) ioapic0: Changing APIC ID to 8 ioapic0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pci0: at device 2.0 (no driver attached) pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 bge0: mem 0xdfdf-0xdfdf irq 16 at device 0.0 on pci2 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:11:11:c3:2c:91 pcib3: irq 17 at device 28.1 on pci0 pci3: on pcib3 pci0: at device 29.0 (no driver attached) pci0: at device 29.1 (no driver attached) pci0: at device 29.2 (no driver attached) pci0: at device 29.3 (no driver attached) pci0: at device 29.7 (no driver attached) pcib4: at device 30.0 on pci0 pci4: on pcib4 atapci0: port 0xdce0-0xdcef,0xdcb4-0xdcb7,0xdcc8-0xdccf,0xdcb0-0xdcb3,0xdcc0-0xdcc7 mem 0xdfaffc00-0xdfaffdff irq 17 at device 1.0 on pci4 ata2: channel #0 on atapci0 ata3: channel #1 on atapci0 atapci1: port 0xdcf0-0xdcff,0xdcbc-0xdcbf,0xdcd8-0xdcdf,0xdcb8-0xdcbb,0xdcd0-0xdcd7 mem 0xdfaffe00-0xdfaf irq 18 at device 2.0 on pci4 ata4: channel #0 on atapci1 ata5: channel #1 on atapci1 isab0: at device 31.0 on pci0 isa0: on isab0 atapci2: port 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 irq 16 at device 31.1 on pci0 ata0: channel #0 on atapci2 ata1: channel #1 on atapci2 atapci3: port 0xfea0-0xfeaf,0xfe30-0xfe33,0xfe20-0xfe27,0xfe10-0xfe13,0xfe00-0xfe07 irq 20 at device 31.2 on pci0 ata6: channel #0 on atapci3 ata7: channel #1 on atapci3 ichsmb0: port 0xece0-0xecff irq 17 at device 31.3 on pci0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 sio0: <16550A-compatible COM port>
Re: panic: Fatal trap 12: page fault while in kernel mode
On Thu, 17 Feb 2005, Rong-En Fan wrote: > On Wed, 16 Feb 2005 15:36:25 -0800 (PST), Doug White > <[EMAIL PROTECTED]> wrote: > > On Wed, 16 Feb 2005, Rong-En Fan wrote: > > > > > Hello, > > > > > > This is a 5.3-RELEASE-p5/amd64 on IBM X236 (EM64T) with 2GB RAM > > > and a LSI 21320 rmpt(4) running at 160MB/s with a hardware > > > RAID (da0, da1). HTT is enabled. When I run benchmark/blogbench on > > > /da0/ I can *reproduce* this panic again and again: > > > (I'm getting a dump now, let me fsck first) > > > kernel conf & dmesg (boot -v) are at > > > http://rafan.infor.org/tmp/236/ > > > > I only have an 2x244 Opteron box so I'm not sure if this is a problem with > > KSE or with hyperthreading. I'll try the benchmark anyway and see if I > > can reproduce. > > > > Looks like I'll need to rebuild first, I'm getting the "exiting from > > __thread_start" error... I got a good -CURRENT build and run this test. It appears to get stuck in an endless loop at the end but no panics result. I also ran it on a i386 -CURRENT machine for comparison and that completed, so this program appears to have 64-bit cleanliness problems. I'll see if I can build a RELENG_5 or 5.3 amd64 box and run the same diagnostic. Its possible its a bug thats been fixed in CURRENT but not backported yet. > If I use machdep.hlt_logical_cpus=1, I got the same panic. > And when I use kgdb to read the kernel dump, I see only > #1 ?? (??) in backtrace. > > I just reinstall the system to 5.3-p5, i386. It does not > panic and finsih the test two times. I'll run more to see if is > panics. > > Regards, > Rong-En Fan > -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: Fatal trap 12: page fault while in kernel mode
On Wed, 16 Feb 2005 15:36:25 -0800 (PST), Doug White <[EMAIL PROTECTED]> wrote: > On Wed, 16 Feb 2005, Rong-En Fan wrote: > > > Hello, > > > > This is a 5.3-RELEASE-p5/amd64 on IBM X236 (EM64T) with 2GB RAM > > and a LSI 21320 rmpt(4) running at 160MB/s with a hardware > > RAID (da0, da1). HTT is enabled. When I run benchmark/blogbench on > > /da0/ I can *reproduce* this panic again and again: > > (I'm getting a dump now, let me fsck first) > > kernel conf & dmesg (boot -v) are at > > http://rafan.infor.org/tmp/236/ > > I only have an 2x244 Opteron box so I'm not sure if this is a problem with > KSE or with hyperthreading. I'll try the benchmark anyway and see if I > can reproduce. > > Looks like I'll need to rebuild first, I'm getting the "exiting from > __thread_start" error... If I use machdep.hlt_logical_cpus=1, I got the same panic. And when I use kgdb to read the kernel dump, I see only #1 ?? (??) in backtrace. I just reinstall the system to 5.3-p5, i386. It does not panic and finsih the test two times. I'll run more to see if is panics. Regards, Rong-En Fan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: Fatal trap 12: page fault while in kernel mode
On Wed, 16 Feb 2005, Rong-En Fan wrote: > Hello, > > This is a 5.3-RELEASE-p5/amd64 on IBM X236 (EM64T) with 2GB RAM > and a LSI 21320 rmpt(4) running at 160MB/s with a hardware > RAID (da0, da1). HTT is enabled. When I run benchmark/blogbench on > /da0/ I can *reproduce* this panic again and again: > (I'm getting a dump now, let me fsck first) > kernel conf & dmesg (boot -v) are at > http://rafan.infor.org/tmp/236/ I only have an 2x244 Opteron box so I'm not sure if this is a problem with KSE or with hyperthreading. I'll try the benchmark anyway and see if I can reproduce. Looks like I'll need to rebuild first, I'm getting the "exiting from __thread_start" error... > > any suggestions are welcome. :) > > Fatal trap 12: page fault while in kernel mode > cpuid = 2; apic id = 06 > fault virtual address = 0x88 > fault code = supervisor read, page not present > instruction pointer = 0x8:0x80235b0b > stack pointer = 0x10:0xb1bd5a50 > frame pointer = 0x10:0xb1bd5a70 > code segment= base 0x0, limit 0xf, type 0x1b >= DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 96 (pagedaemon) > [thread 100114] > Stopped at thread_fini+0xab: subl0x88(%ebx),%eax > db> trace > thread_fini() at thread_fini+0xab > zone_drain() at zone_drain+0x22d > zone_foreach() at zone_foreach+0x76 > uma_reclaim() at uma_reclaim+0x15 > vm_pageout_scan() at vm_pageout_scan+0x170 > vm_pageout() at vm_pageout+0x38e > fork_exit() at fork_exit+0xaa > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xb1bd5d00, rbp = 0 --- > db> ps > pid proc uarea uid ppid pgrp flag stat wmesgwchan cmd > 615 ff00603348b8 b43b50000 568 615 000c082 > (threaded) blogbench > thread 0xff001e7ef000 ksegrp 0xff007b1fb4d0 [RUNQ] > thread 0xff000881fa40 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99d19c40][SLP] > thread 0xff001c25d520 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99d37640][SLP] > thread 0xff000881fcd0 ksegrp 0xff007b1fb4d0 [RUNQ] > thread 0xff001ffa27b0 ksegrp 0xff007b1fb4d0 [RUNQ] > thread 0xff001b755520 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x9a373640][SLP] > thread 0xff0070700a40 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x9a2d8b40][SLP] > thread 0xff002c333cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99f1c140][SLP] > thread 0xff00462e0520 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x9a104e40][SLP] > thread 0xff0011002a40 ksegrp 0xff007b1fb4d0 [SLPQ ufs > 0xff0059594c80][SLP] > thread 0xff006310f7b0 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x9a237740][SLP] > thread 0xff003c731520 ksegrp 0xff007b1fb4d0 [SLPQ ufs > 0xff00087c1500][SLP] > thread 0xff0033c33290 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99ee8e40][SLP] > thread 0xff00635a7290 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99d86840][SLP] > thread 0xff006ff7ccd0 ksegrp 0xff007b1fb4d0 [RUNQ] > thread 0xff000881f520 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99fbb440][SLP] > thread 0xff006eff2520 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99a01640][SLP] > thread 0xff004d176520 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x9a069140][SLP] > thread 0xff0048ded520 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99f9c540][SLP] > thread 0xff003689f7b0 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99d7c940][SLP] > thread 0xff0052446cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99f22d40][SLP] > thread 0xff006eff2000 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99a6c140][SLP] > thread 0xff0054121cd0 ksegrp 0xff007b1fb4d0 [SLPQ ufs > 0xff0059112500][SLP] > thread 0xff00492bc000 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x9a315440][SLP] > thread 0xff003289ba40 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99ff1d40][SLP] > thread 0xff0055b3ea40 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99fe2140][SLP] > thread 0xff0055b3e000 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x999d1340][SLP] > thread 0xff003689f290 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x9a2bc040][SLP] > thread 0xff000881f000 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99bc8440][SLP] > thread 0xff006ff7c000 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99c2ed40][SLP] > thread 0xff003289b000 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x9a0c0a40][SLP] > thread 0xff003c731a40 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99c9ec40][SLP] > thread 0xff0009f50cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99b1c240][SLP] > thread 0xff000dbd5cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x9a1ff
panic: Fatal trap 12: page fault while in kernel mode
Hello, This is a 5.3-RELEASE-p5/amd64 on IBM X236 (EM64T) with 2GB RAM and a LSI 21320 rmpt(4) running at 160MB/s with a hardware RAID (da0, da1). HTT is enabled. When I run benchmark/blogbench on /da0/ I can *reproduce* this panic again and again: (I'm getting a dump now, let me fsck first) kernel conf & dmesg (boot -v) are at http://rafan.infor.org/tmp/236/ any suggestions are welcome. :) Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 06 fault virtual address = 0x88 fault code = supervisor read, page not present instruction pointer = 0x8:0x80235b0b stack pointer = 0x10:0xb1bd5a50 frame pointer = 0x10:0xb1bd5a70 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 96 (pagedaemon) [thread 100114] Stopped at thread_fini+0xab: subl0x88(%ebx),%eax db> trace thread_fini() at thread_fini+0xab zone_drain() at zone_drain+0x22d zone_foreach() at zone_foreach+0x76 uma_reclaim() at uma_reclaim+0x15 vm_pageout_scan() at vm_pageout_scan+0x170 vm_pageout() at vm_pageout+0x38e fork_exit() at fork_exit+0xaa fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xb1bd5d00, rbp = 0 --- db> ps pid proc uarea uid ppid pgrp flag stat wmesgwchan cmd 615 ff00603348b8 b43b50000 568 615 000c082 (threaded) blogbench thread 0xff001e7ef000 ksegrp 0xff007b1fb4d0 [RUNQ] thread 0xff000881fa40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d19c40][SLP] thread 0xff001c25d520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d37640][SLP] thread 0xff000881fcd0 ksegrp 0xff007b1fb4d0 [RUNQ] thread 0xff001ffa27b0 ksegrp 0xff007b1fb4d0 [RUNQ] thread 0xff001b755520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a373640][SLP] thread 0xff0070700a40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a2d8b40][SLP] thread 0xff002c333cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99f1c140][SLP] thread 0xff00462e0520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a104e40][SLP] thread 0xff0011002a40 ksegrp 0xff007b1fb4d0 [SLPQ ufs 0xff0059594c80][SLP] thread 0xff006310f7b0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a237740][SLP] thread 0xff003c731520 ksegrp 0xff007b1fb4d0 [SLPQ ufs 0xff00087c1500][SLP] thread 0xff0033c33290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99ee8e40][SLP] thread 0xff00635a7290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d86840][SLP] thread 0xff006ff7ccd0 ksegrp 0xff007b1fb4d0 [RUNQ] thread 0xff000881f520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99fbb440][SLP] thread 0xff006eff2520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99a01640][SLP] thread 0xff004d176520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a069140][SLP] thread 0xff0048ded520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99f9c540][SLP] thread 0xff003689f7b0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d7c940][SLP] thread 0xff0052446cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99f22d40][SLP] thread 0xff006eff2000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99a6c140][SLP] thread 0xff0054121cd0 ksegrp 0xff007b1fb4d0 [SLPQ ufs 0xff0059112500][SLP] thread 0xff00492bc000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a315440][SLP] thread 0xff003289ba40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99ff1d40][SLP] thread 0xff0055b3ea40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99fe2140][SLP] thread 0xff0055b3e000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x999d1340][SLP] thread 0xff003689f290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a2bc040][SLP] thread 0xff000881f000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99bc8440][SLP] thread 0xff006ff7c000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99c2ed40][SLP] thread 0xff003289b000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a0c0a40][SLP] thread 0xff003c731a40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99c9ec40][SLP] thread 0xff0009f50cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99b1c240][SLP] thread 0xff000dbd5cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a1fff40][SLP] thread 0xff003c9bdcd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d06440][SLP] thread 0xff003c9bd7b0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a202c40][SLP] thread 0xff006ac1ba40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a30c740][SLP] thread 0xff00342f4290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a00ee40][SLP] thread 0xff004819d290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99dc3440][SLP] thread 0xff005cd927b0 ksegrp 0xf
panic: Fatal trap 12: page fault while in kernel mode
Hello, This is a 5.3-RELEASE-p5/amd64 on IBM X236 (EM64T) with 2GB RAM and a LSI 21320 rmpt(4) running at 160MB/s with a hardware RAID (da0, da1). HTT is enabled. When I run benchmark/blogbench on /da0/ I can *reproduce* this panic again and again: (I'm getting a dump now, let me fsck first) kernel conf & dmesg (boot -v) are at http://rafan.infor.org/tmp/236/ any suggestions are welcome. :) Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 06 fault virtual address = 0x88 fault code = supervisor read, page not present instruction pointer = 0x8:0x80235b0b stack pointer = 0x10:0xb1bd5a50 frame pointer = 0x10:0xb1bd5a70 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 96 (pagedaemon) [thread 100114] Stopped at thread_fini+0xab: subl0x88(%ebx),%eax db> trace thread_fini() at thread_fini+0xab zone_drain() at zone_drain+0x22d zone_foreach() at zone_foreach+0x76 uma_reclaim() at uma_reclaim+0x15 vm_pageout_scan() at vm_pageout_scan+0x170 vm_pageout() at vm_pageout+0x38e fork_exit() at fork_exit+0xaa fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xb1bd5d00, rbp = 0 --- db> ps pid proc uarea uid ppid pgrp flag stat wmesgwchan cmd 615 ff00603348b8 b43b50000 568 615 000c082 (threaded) blogbench thread 0xff001e7ef000 ksegrp 0xff007b1fb4d0 [RUNQ] thread 0xff000881fa40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d19c40][SLP] thread 0xff001c25d520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d37640][SLP] thread 0xff000881fcd0 ksegrp 0xff007b1fb4d0 [RUNQ] thread 0xff001ffa27b0 ksegrp 0xff007b1fb4d0 [RUNQ] thread 0xff001b755520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a373640][SLP] thread 0xff0070700a40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a2d8b40][SLP] thread 0xff002c333cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99f1c140][SLP] thread 0xff00462e0520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a104e40][SLP] thread 0xff0011002a40 ksegrp 0xff007b1fb4d0 [SLPQ ufs 0xff0059594c80][SLP] thread 0xff006310f7b0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a237740][SLP] thread 0xff003c731520 ksegrp 0xff007b1fb4d0 [SLPQ ufs 0xff00087c1500][SLP] thread 0xff0033c33290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99ee8e40][SLP] thread 0xff00635a7290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d86840][SLP] thread 0xff006ff7ccd0 ksegrp 0xff007b1fb4d0 [RUNQ] thread 0xff000881f520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99fbb440][SLP] thread 0xff006eff2520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99a01640][SLP] thread 0xff004d176520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a069140][SLP] thread 0xff0048ded520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99f9c540][SLP] thread 0xff003689f7b0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d7c940][SLP] thread 0xff0052446cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99f22d40][SLP] thread 0xff006eff2000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99a6c140][SLP] thread 0xff0054121cd0 ksegrp 0xff007b1fb4d0 [SLPQ ufs 0xff0059112500][SLP] thread 0xff00492bc000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a315440][SLP] thread 0xff003289ba40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99ff1d40][SLP] thread 0xff0055b3ea40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99fe2140][SLP] thread 0xff0055b3e000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x999d1340][SLP] thread 0xff003689f290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a2bc040][SLP] thread 0xff000881f000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99bc8440][SLP] thread 0xff006ff7c000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99c2ed40][SLP] thread 0xff003289b000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a0c0a40][SLP] thread 0xff003c731a40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99c9ec40][SLP] thread 0xff0009f50cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99b1c240][SLP] thread 0xff000dbd5cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a1fff40][SLP] thread 0xff003c9bdcd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d06440][SLP] thread 0xff003c9bd7b0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a202c40][SLP] thread 0xff006ac1ba40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a30c740][SLP] thread 0xff00342f4290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a00ee40][SLP] thread 0xff004819d290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99dc3440][
Re: 4.10 kernel panic: Fatal trap 12: page fault while in kernel mode
In message <[EMAIL PROTECTED]>, Peter Jeremy wri tes: >On Wed, Dec 15, 2004 at 12:42:25PM -0800, Scott Sewall wrote: >> I'm running FreeBSD 4.10-RELEASE-p3 that occasionally panics. The panic >> occurs seems to happen when I'm running rsync of large directories >> possibly in combination with reading or writing to a compact flash >> attached to USB. > >Having just looked into an identical panic, the problem is an >interface bug between bus_dmamem_alloc() and contigmalloc(). It's >nothing to do with USB and (AFAIK) exists in 4.x, 5.x and 6.x. The USB code is not entirely free of blame here however. It allocates numerous big chunks of contiguous memory for tranfer buffers instead of using the (admittedly limited) scatter-gather capabilities of the USB host controllers. Try applying the change from revision 1.6 of usb_mem.c. This fixed one particularly inefficient memory use behaviour in the USB code. That change is already in 5.x and 6.x, but wasn't merged to 4.x. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/usb_mem.c Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 4.10 kernel panic: Fatal trap 12: page fault while in kernel mode
On Wed, Dec 15, 2004 at 12:42:25PM -0800, Scott Sewall wrote:
> I'm running FreeBSD 4.10-RELEASE-p3 that occasionally panics. The panic
> occurs seems to happen when I'm running rsync of large directories
> possibly in combination with reading or writing to a compact flash
> attached to USB.
Having just looked into an identical panic, the problem is an
interface bug between bus_dmamem_alloc() and contigmalloc(). It's
nothing to do with USB and (AFAIK) exists in 4.x, 5.x and 6.x.
The relevant part of my backtrace looks like:
#15 0xc028aaef in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 0,
tf_esi = -980715140, tf_ebp = -1070676940, tf_isp = -1070676996,
tf_ebx = 0, tf_edx = 6867008, tf_ecx = -1056660992, tf_eax = 7261248,
tf_trapno = 12, tf_err = 0, tf_eip = -1072225192, tf_cs = 8,
tf_eflags = 66118, tf_esp = -1065633592, tf_ss = 0})
at /home/src/sys/i386/i386/trap.c:466
#16 0xc0172458 in tsleep (ident=0xc58b797c, priority=4,
wmesg=0xc02bfd27 "swwrt", timo=0) at /home/src/sys/kern/kern_synch.c:436
#17 0xc021e60f in swap_pager_putpages (object=0xd03c6e04, m=0xc02ec50c,
count=1, sync=1, rtvals=0xc02ec4b0) at /home/src/sys/vm/swap_pager.c:1431
#18 0xc021ceaf in default_pager_putpages (object=0xd03c6e04, m=0xc02ec50c,
c=1, sync=0, rtvals=0xc02ec4b0) at /home/src/sys/vm/default_pager.c:133
#19 0xc0228ca4 in vm_pageout_flush (mc=0xc02ec50c, count=1, flags=0)
at /home/src/sys/vm/vm_pager.h:147
#20 0xc02285c9 in contigmalloc1 (size=36864, type=0xc02f4340, flags=1, low=0,
high=4294967295, alignment=1, boundary=0, map=0xc03372ac)
at /home/src/sys/vm/vm_page.c:1855
#21 0xc022887f in contigmalloc (size=36864, type=0xc02f4340, flags=1, low=0,
high=4294967295, alignment=1, boundary=0)
at /home/src/sys/vm/vm_page.c:1980
#22 0xc027bd3b in bus_dmamem_alloc (dmat=0xc176b4c0, vaddr=0xc1231a48,
flags=1, mapp=0xc1231a44) at /home/src/sys/i386/i386/busdma_machdep.c:351
#23 0xc0231be2 in usb_block_allocmem (tag=0x0, size=36864, align=1,
dmap=0xc17d8d3c) at /home/src/sys/dev/usb/usb_mem.c:186
...
#35 0xc022d4ea in uhci_intr (arg=0xc104f000)
at /home/src/sys/dev/usb/uhci.c:1175
#36 0xc02841f2 in cpu_idle () at /home/src/sys/i386/i386/machdep.c:1000
Basically, the USB code is trying to allocate ~36KB RAM within an
interrupt handler. usb_block_allocmem() invokes bus_dmamem_alloc()
with BUS_DMA_NOWAIT (advising that sleep()ing is not allowed).
Since more than one page of memory is requested, bus_dmamem_alloc()
uses contigmalloc() to allocate the requested memory. The BUS_DMA_NOWAIT
flag is mapped to M_NOWAIT but contigmalloc() does not support M_NOWAIT.
Unfortunately, I don't know enough about the VM code to be able to
suggest a fix.
--
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 4.10 kernel panic: Fatal trap 12: page fault while in kernel mode
On Wed, Dec 15, 2004 at 12:42:25PM -0800, Scott Sewall wrote: > > I'm running FreeBSD 4.10-RELEASE-p3 that occasionally panics. The panic > occurs seems to happen when I'm running rsync of large directories > possibly in combination with reading or writing to a compact flash > attached to USB. > > I've attached the panic message, dmesg output, and gdb output. > > If there's any additional informtion I can provide to try and resolve > the problem, please ask. I'm willing to put some effort into fixing the > problem. > > Any and all help is greatly appreciated. Yeah, looks like the USB code is implicated. You might like to try 5.3 or RELENG_5, I think there was some work done there to clean it up a bit. Kris pgpZbF4rqLSAB.pgp Description: PGP signature
4.10 kernel panic: Fatal trap 12: page fault while in kernel mode
I'm running FreeBSD 4.10-RELEASE-p3 that occasionally panics. The panic occurs seems to happen when I'm running rsync of large directories possibly in combination with reading or writing to a compact flash attached to USB. I've attached the panic message, dmesg output, and gdb output. If there's any additional informtion I can provide to try and resolve the problem, please ask. I'm willing to put some effort into fixing the problem. Any and all help is greatly appreciated. -- Scott Fatal trap 12: page fault while in kernel mode mp_lock = 0102; cpuid = 1; lapic.id = 0100 fault virtual address = 0x70 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0172b0c stack pointer = 0x10:0xffc11cf0 frame pointer = 0x10:0xffc11d14 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = net tty bio cam <- SMP: XXX trap number = 12 panic: page fault mp_lock = 0102; cpuid = 1; lapic.id = 0100 boot() called on cpu#1 Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.10-RELEASE-p3 #1: Thu Nov 11 20:54:12 PST 2004 [EMAIL PROTECTED]:/usr/src/sys/compile/LILO Timecounter "i8254" frequency 1193182 Hz CPU: Intel Pentium III (930.39-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x387fbff real memory = 4227858432 (4128768K bytes) config> di bt0 No such device: bt0 Invalid command or syntax. Type `?' for help. config> di aic0 No such device: aic0 Invalid command or syntax. Type `?' for help. config> di aha0 No such device: aha0 Invalid command or syntax. Type `?' for help. config> di adv0 No such device: adv0 Invalid command or syntax. Type `?' for help. config> q avail memory = 4119408640 (4022860K bytes) Programming 16 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 Programming 16 pins in IOAPIC #1 FreeBSD/SMP: Multiprocessor motherboard: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 4, version: 0x000f0011, at 0xfec0 io1 (APIC): apic id: 5, version: 0x000f0011, at 0xfec01000 Preloaded elf kernel "kernel" at 0xc03af000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc03af09c. Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 10 entries at 0xc00f51d0 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard IOAPIC #1 intpin 6 -> irq 2 IOAPIC #1 intpin 4 -> irq 9 IOAPIC #1 intpin 5 -> irq 10 IOAPIC #0 intpin 10 -> irq 11 pci0: on pcib0 pci0: at 1.0 irq 2 fxp0: port 0xd400-0xd43f mem 0xfe90-0xfe9f,0xfeafe000-0xfeafefff irq 9 at device 4.0 on pci0 fxp0: Ethernet address 00:e0:81:02:11:cc inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: port 0xd000-0xd03f mem 0xfe70-0xfe7f,0xfeafd000-0xfeafdfff irq 10 at device 5.0 on pci0 fxp1: Ethernet address 00:e0:81:02:11:cd inphy1: on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: at device 15.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ohci0: mem 0xfeafc000-0xfeafcfff irq 11 at device 15.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered umass0: vendor 0x55aa USB 2.0 7-2-2, rev 2.00/2.00, addr 2 pcib1: on motherboard pci1: on pcib1 orm0: at iomem 0xc-0xc7fff,0xc8000-0xc8fff,0xc9000-0xc9fff on isa0 pmtimer0 on isa0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: parallel port not found. APIC_IO: Testing 8254 interrupt delivery APIC_IO: Broken MP table detected: 8254 is not connected to IOAPIC #0 intpin 2 APIC_IO: routing 8254 via 8259 and IOAPIC #0 intpin 0 SMP: AP CPU #1 Launched! ad0: 238475MB [484521/16/63] at ata0-master UDMA33 ad1: 238475MB [484521/16/63] at ata0-slave UDMA33 acd0: DVD-R at ata1-master UDMA33 Mounting root from ufs:/dev/ad0s1a cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd
