Date: Wed, 17 Sep 2014 12:36:30 +0200 From: Fabian Keil <freebsd-listen@fabiankeil.de> To: <freebsd-fs@FreeBSD.org> Subject: General protection fault after setting vfs.zfs.vdev.aggregation_limit above SPA_MAXBLOCKSIZE Message-ID: <3e120694.116e4008@fabiankeil.de>
next in thread | raw e-mail | index | archive | help
--Sig_/z5ih3lfyzX0li78VDDYUBRP
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
For testing purposes I reduced vfs.zfs.vdev.aggregation_limit
to 32768 and later on set it "back" to 128000 followed by 132768
(not remembering the default and being to lazy to look it up).
A couple of seconds after the last change I got the following panic:
fk@r500 /usr/crash $kgdb kernel.1/kernel.symbols vmcore.1
[...]
Unread portion of the kernel message buffer:
[24663]=20
[24663]=20
[24663] Fatal trap 9: general protection fault while in kernel mode
[24663] cpuid =3D 0; apic id =3D 00
[24663] instruction pointer =3D 0x20:0xffffffff810ec708
[24663] stack pointer =3D 0x28:0xfffffe0094e77340
[24663] frame pointer =3D 0x28:0xfffffe0094e77350
[24663] code segment =3D base 0x0, limit 0xfffff, type 0x1b
[24663] =3D DPL 0, pres 1, long 1, def32 0, gran 1
[24663] processor eflags =3D interrupt enabled, resume, IOPL =3D 0
[24663] current process =3D 11715 (rsync)
[24663] Uptime: 6h51m3s
[24663] Dumping 317 out of 1973 MB:..6%..11%..21%..31%..41%..51%..61%..71%.=
.81%..91%
[...]
Loaded symbols for /usr/crash/kernel.1/geom_gate.ko.symbols
#0 doadump (textdump=3D1) at pcpu.h:219
219 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) where
#0 doadump (textdump=3D1) at pcpu.h:219
#1 0xffffffff8059799d in kern_reboot (howto=3D260) at /usr/src/sys/kern/ke=
rn_shutdown.c:447
#2 0xffffffff80597ef0 in panic (fmt=3D<value optimized out>) at /usr/src/s=
ys/kern/kern_shutdown.c:746
#3 0xffffffff8030ef57 in db_panic (addr=3D<value optimized out>, have_addr=
=3D-10592, count=3D0, modif=3D0x0) at /usr/src/sys/ddb/db_command.c:482
#4 0xffffffff8030eb6d in db_command (cmd_table=3D0x0) at /usr/src/sys/ddb/=
db_command.c:449
#5 0xffffffff8030e8e4 in db_command_loop () at /usr/src/sys/ddb/db_command=
.c:502
#6 0xffffffff80311340 in db_trap (type=3D<value optimized out>, code=3D0) =
at /usr/src/sys/ddb/db_main.c:231
#7 0xffffffff805d7da1 in kdb_trap (type=3D9, code=3D0, tf=3D<value optimiz=
ed out>) at /usr/src/sys/kern/subr_kdb.c:654
#8 0xffffffff8085b83c in trap_fatal (frame=3D0xfffffe0094e77290, eva=3D<va=
lue optimized out>) at /usr/src/sys/amd64/amd64/trap.c:861
#9 0xffffffff8085b4de in trap (frame=3D<value optimized out>) at /usr/src/=
sys/amd64/amd64/trap.c:201
#10 0xffffffff8083f552 in calltrap () at /usr/src/sys/amd64/amd64/exception=
.S:231
#11 0xffffffff810ec708 in list_prev (list=3D0xffffffff81223038, object=3D0x=
5345413a317652ac) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/os/li=
st.c:183
#12 0xffffffff810f9d7e in arc_evict (state=3D0xffffffff81222d00, spa=3D0, b=
ytes=3D131072, recycle=3D<value optimized out>, type=3DARC_BUFC_DATA) at /u=
sr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:2037
#13 0xffffffff810f8695 in arc_get_data_buf (buf=3D0xfffff8006e6f43a8) at /u=
sr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:2865
#14 0xffffffff810f88d6 in arc_loan_buf (spa=3D<value optimized out>, size=
=3D131072) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c=
:1544
#15 0xffffffff8110bb61 in dmu_request_arcbuf (handle=3D<value optimized out=
>, size=3D0) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu=
.c:1299
#16 0xffffffff8119d390 in zfs_freebsd_write (ap=3D<value optimized out>) at=
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:989
#17 0xffffffff808ea0f5 in VOP_WRITE_APV (vop=3D<value optimized out>, a=3D<=
value optimized out>) at vnode_if.c:997
#18 0xffffffff80663c89 in vn_write (fp=3D0xfffff8005bf4c320, uio=3D0xfffffe=
0094e77ab0, active_cred=3D<value optimized out>, flags=3D160, td=3D0x3e26) =
at vnode_if.h:413
#19 0xffffffff8065fa1b in vn_io_fault (fp=3D0xfffff8005bf4c320, uio=3D0xfff=
ffe0094e77ab0, active_cred=3D0x5345413a317652ac, flags=3D0, td=3D0x3e26) at=
/usr/src/sys/kern/vfs_vnops.c:1150
#20 0xffffffff805f31f7 in dofilewrite (td=3D0xfffff8006ec64920, fd=3D3, fp=
=3D0xfffff8005bf4c320, auio=3D0xfffffe0094e77ab0, offset=3D<value optimized=
out>, flags=3D0) at file.h:299
#21 0xffffffff805f2f28 in kern_writev (td=3D0xfffff8006ec64920, fd=3D3, aui=
o=3D0xfffffe0094e77ab0) at /usr/src/sys/kern/sys_generic.c:467
#22 0xffffffff805f2eb3 in sys_write (td=3D<value optimized out>, uap=3D<val=
ue optimized out>) at /usr/src/sys/kern/sys_generic.c:382
#23 0xffffffff8085c2db in amd64_syscall (td=3D0xfffff8006ec64920, traced=3D=
0) at subr_syscall.c:133
#24 0xffffffff8083f83b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exce=
ption.S:390
#25 0x0000000800e0840a in ?? ()
Previous frame inner to this frame (corrupt stack?)
Current language: auto; currently minimal
(kgdb) f 11
#11 0xffffffff810ec708 in list_prev (list=3D0xffffffff81223038, object=3D0x=
5345413a317652ac) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/os/li=
st.c:183
183 list_node_t *node =3D list_d2l(list, object);
(kgdb) p *list
$1 =3D {list_size =3D 216, list_offset =3D 160, list_head =3D {list_next =
=3D 0xfffff80059681328, list_prev =3D 0xfffff80058a53328}}
(kgdb) p *(arc_buf_hdr_t *)object
Cannot access memory at address 0x5345413a317652ac
The system is FreeBSD 11.0-CURRENT based on r271610.
Assuming this was actually caused by the vfs.zfs.vdev.aggregation_limit
modification I'm unlikely to run into it again, but I'm wondering if it
is the expected and intended behaviour.
Fabian
--Sig_/z5ih3lfyzX0li78VDDYUBRP
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlQZZC0ACgkQBYqIVf93VJ1yBACgu6ix9PicQYculHevqF24UKnM
c8MAmwTBgCfdPlLlcIEJz7eK4jT4Bq4b
=qHOZ
-----END PGP SIGNATURE-----
--Sig_/z5ih3lfyzX0li78VDDYUBRP--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3e120694.116e4008>