Bug 196498 - zpool panic creating file-backed pools
Summary: zpool panic creating file-backed pools
Status: Closed DUPLICATE of bug 195061
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.1-STABLE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
Depends on:
Reported: 2015-01-05 04:03 UTC by Michael Dexter
Modified: 2015-01-28 21:31 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Michael Dexter 2015-01-05 04:03:26 UTC
File-backed zpools appear to experienced a regression in 10.1, resulting in a panic. This bug appears to be absent in 9.3 and 10-STABLE.

To reproduce it:

# truncate -s 300M foo.img
# zpool create foo /dev/foo.img

Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address	= 0x0
fault code		= supervisor read data, page not present
instruction pointer	= 0x20:0xffffffff80d3e2d6
stack pointer	        = 0x28:0xfffffe011efbce50
frame pointer	        = 0x28:0xfffffe011efbceb0
code segment		= base rx0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 0
current process		= 1040 (zpool)
[ thread pid 1040 tid 100401 ]
Stopped at      bcopy+0x16:     repe movsq      (%rsi),%es:(%rdi)
db> bt
Tracing pid 1040 tid 100401 td 0xfffff8000b976920
bcopy() at bcopy+0x16/frame 0xfffffe011efbceb0
dmu_write_uio_dnode() at dmu_write_uio_dnode+0xcc/frame 0xfffffe011efbcf30
dmu_write_uio_dbuf() at dmu_write_uio_dbuf+0x3b/frame 0xfffffe011efbcf60
zfs_freebsd_write() at zfs_freebsd_write+0x5e2/frame 0xfffffe011efbd190
VOP_WRITE_APV() at VOP_WRITE_APV+0x145/frame 0xfffffe011efbd2a0
vn_rdwr() at vn_rdwr+0x299/frame 0xfffffe011efbd380
vdev_file_io_start() at vdev_file_io_start+0x165/frame 0xfffffe011efbd400
zio_vdev_io_start() at zio_vdev_io_start+0x326/frame 0xfffffe011efbd460
zio_execute() at zio_execute+0x162/frame 0xfffffe011efbd4c0
zio_wait() at zio_wait+0x23/frame 0xfffffe011efbd4f0
vdev_label_init() at vdev_label_init+0x22d/frame 0xfffffe011efbd5c0
vdev_label_init() at vdev_label_init+0x57/frame 0xfffffe011efbd690
vdev_create() at vdev_create+0x54/frame 0xfffffe011efbd6c0
spa_create() at spa_create+0x217/frame 0xfffffe011efbd750
zfs_ioc_pool_create() at zfs_ioc_pool_create+0x25d/frame 0xfffffe011efbd7d0
zfsdev_ioctl() at zfsdev_ioctl+0x6f0/frame 0xfffffe011efbd890
devfs_ioctl_f() at devfs_ioctl_f+0x114/frame 0xfffffe011efbd8e0
kern_ioctl() at kern_ioctl+0x255/frame 0xfffffe011efbd950
sys_ioctl() at sys_ioctl+0x13c/frame 0xfffffe011efbd9a0
amd64_syscall() at amd64_syscall+0x351/frame 0xfffffe011efbdab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe011efbdab0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8019f9b9a, rsp = 0x7fffffffb9e8, rbp = 0x7fffffffba60 ---

I have tested this with 64M (ZFS minimum) through 300M virtual block devices.

Confirmed by grehan@

Removing this functionality is not a valid solution.
Comment 1 Michael Dexter 2015-01-28 21:23:38 UTC
The original report should read:

zpool create foo /root/foo.img


zpool create foo /dev/foo.img

Attaching the same file with 'mdconfig -af /root/foo.img' and 'zpool create foo md0' works fine.
Comment 2 Xin LI freebsd_committer 2015-01-28 21:27:34 UTC

*** This bug has been marked as a duplicate of bug 195061 ***