Date: Thu, 21 May 2009 11:31:38 -0700 From: Kip Macy <kmacy@freebsd.org> To: Thomas Backman <serenity@exscape.org> Cc: current@freebsd.org Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS Message-ID: <3c1674c90905211131q607e05a9m68e906f2d3620414@mail.gmail.com> In-Reply-To: <E419A991-E81E-44D8-9E17-1027B56AAD48@exscape.org> References: <20090518145614.GF82547@egr.msu.edu> <alpine.BSF.2.00.0905181031240.35767@thebighonker.lerctr.org> <alpine.BSF.2.00.0905181830490.1756@borg> <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> <alpine.BSF.2.00.0905181906001.2008@borg> <3c1674c90905181800x469d3cabx5df959d3585b4b5a@mail.gmail.com> <040ce5cee10b3b92fd127bbce83f4c77.squirrel@webmail.lerctr.org> <3c1674c90905181815r49a5bbe2u5d4a73e4f91f89a6@mail.gmail.com> <E419A991-E81E-44D8-9E17-1027B56AAD48@exscape.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Hey, I (not the OP) am still having trouble with this. The panics appear = to > be gone since I set arc_min to 30M and arc_max to 100M, though (2GB RAM). > I get/got them during a full zfs send -R | zfs recv -Fvd of a ~3.3GB pool= . > The only modification I've done to the source tree is the libzfs_sendrecv > patch here: > http://lists.freebsd.org/pipermail/freebsd-current/2009-May/006814.html I'll apply the patch this weekend. If I get time I'll also try to reproduce your panic. Thanks, Kip > > FreeBSD chaos.exscape.org 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Wed May 20 > 21:19:29 CEST 2009 =A0 =A0 root@chaos.exscape.org:/usr/obj/usr/src/sys/DT= RACE > =A0amd64 > (GENERIC + the 3 DTrace lines added) > > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > fault virtual address =A0 =3D 0x0 > fault code =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D supervisor write data, page not= present > instruction pointer =A0 =A0 =3D 0x20:0xffffffff8085e89a > stack pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xffffff803ea4e4d0 > frame pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xffffff803ea4e590 > code segment =A0 =A0 =A0 =A0 =A0 =A0=3D base 0x0, limit 0xfffff, type 0x1= b > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D DPL 0, pres 1, long 1,= def32 0, gran 1 > processor eflags =A0 =A0 =A0 =A0=3D interrupt enabled, resume, IOPL =3D 0 > current process =A0 =A0 =A0 =A0 =3D 1281 (zfs) > > vmstat -s from core.txt shows 388955 pages wired down - I take it that's > 388955*4 kiB or almost 1.5GB out of 2GB. 110685 pages are still free, if > that's relevant (I'm not sure why the crash occurs, but I guess it might > be). > > Backtrace: > #0 =A0doadump () at pcpu.h:223 > 223 =A0 =A0 pcpu.h: No such file or directory. > =A0 =A0 =A0 =A0in pcpu.h > (kgdb) #0 =A0doadump () at pcpu.h:223 > #1 =A00xffffffff80576089 in boot (howto=3D260) > =A0 =A0at /usr/src/sys/kern/kern_shutdown.c:420 > #2 =A00xffffffff805764dc in panic (fmt=3DVariable "fmt" is not available. > ) > =A0 =A0at /usr/src/sys/kern/kern_shutdown.c:576 > #3 =A00xffffffff801d5a97 in db_panic (addr=3DVariable "addr" is not avail= able. > ) > =A0 =A0at /usr/src/sys/ddb/db_command.c:478 > #4 =A00xffffffff801d5ea1 in db_command (last_cmdp=3D0xffffffff80bd7c20, > cmd_table=3DVariable "cmd_table" is not available. > > ) at /usr/src/sys/ddb/db_command.c:445 > #5 =A00xffffffff801d60f0 in db_command_loop () > =A0 =A0at /usr/src/sys/ddb/db_command.c:498 > #6 =A00xffffffff801d8089 in db_trap (type=3DVariable "type" is not availa= ble. > ) at /usr/src/sys/ddb/db_main.c:229 > #7 =A00xffffffff805a6bb5 in kdb_trap (type=3D12, code=3D0, tf=3D0xffffff8= 03ea4e420) > =A0 =A0at /usr/src/sys/kern/subr_kdb.c:534 > #8 =A00xffffffff808603bd in trap_fatal (frame=3D0xffffff803ea4e420, eva= =3DVariable > "eva" is not available. > ) > =A0 =A0at /usr/src/sys/amd64/amd64/trap.c:847 > #9 =A00xffffffff80860794 in trap_pfault (frame=3D0xffffff803ea4e420, user= mode=3D0) > =A0 =A0at /usr/src/sys/amd64/amd64/trap.c:768 > #10 0xffffffff80861283 in trap (frame=3D0xffffff803ea4e420) > =A0 =A0at /usr/src/sys/amd64/amd64/trap.c:494 > #11 0xffffffff8083ae57 in calltrap () > =A0 =A0at /usr/src/sys/amd64/amd64/exception.S:223 > #12 0xffffffff8085e89a in bzero () at /usr/src/sys/amd64/amd64/support.S:= 64 > #13 0xffffffff80e8aab1 in dbuf_read () from /boot/kernel/zfs.ko > #14 0xffffffff80e8a12e in dmu_buf_rele () from /boot/kernel/zfs.ko > #15 0xffffff0002e34460 in ?? () > #16 0x0000000000000000 in ?? () > #17 0x0000000000000000 in ?? () > #18 0x000000003ea4e570 in ?? () > #19 0xffffff003533c2d0 in ?? () > #20 0xffffff803ea4e588 in ?? () > #21 0xffffff8004619240 in ?? () > #22 0xffffff00415591c0 in ?? () > #23 0x0000000000000000 in ?? () > #24 0x0000000000000000 in ?? () > #25 0x000000044153f300 in ?? () > #26 0x0000000000000000 in ?? () > #27 0xffffff0002e34460 in ?? () > #28 0x0000000000000005 in ?? () > #29 0xffffff004153f300 in ?? () > #30 0x0000000000000000 in ?? () > #31 0x000000000000da01 in ?? () > #32 0xffffff803ea4e5c0 in ?? () > #33 0xffffffff80e963ea in dmu_tx_check_ioerr () from /boot/kernel/zfs.ko > > Regards, > Thomas > > PS. I have the full core.txt if it'd help. DS. > --=20 When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3c1674c90905211131q607e05a9m68e906f2d3620414>