Bug 145272 - [zfs] [panic] Panic during boot when accessing zfs on a gmirror
Summary: [zfs] [panic] Panic during boot when accessing zfs on a gmirror
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 8.0-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords: crash
Depends on:
Blocks:
 
Reported: 2010-04-01 22:50 UTC by Christopher Key
Modified: 2022-10-17 07:19 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Key 2010-04-01 22:50:07 UTC
Panic during boot when accessing zfs on a gmirror.

This appears to have become a problem between 7.2-RELEASE and 8.0-RELEASE.  The steps below that reproduce the problem haven't been directly tested on a 7.2 system, but a similar configuration (zpool on a single slice on a gmirror) that worked under 7.2 shows identical symptoms under 8.0.

How-To-Repeat: 
# gmirror label gmtest /dev/da5
# zpool create zptest /dev/mirror/gmtest
# zpool export zptest
# reboot

... system boots fine.

# zpool import zptest
# reboot

... during boot:

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x0
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff80aa7dfe
stack pointer           = 0x28:0xffffff803f8a06e0
frame pointer           = 0x28:0xffffff803f8a0740
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         = 42 (zfs)
trap number             = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
panic() at panic+0x182
trap_fatal() at trap_fatal+0x2ad
trap_pfault() at trap_pfault+0x294
trap() at trap+0x3cf
calltrap() at calltrap+0x8
--- trap 0xc, rip = 0xffffffff80aa7dfe, rsp = 0xffffff803f8a06e0, rbp = 0xffffff                                                                             803f8a0740 ---
vdev_geom_open() at vdev_geom_open+0x10e
vdev_open() at vdev_open+0xa8
vdev_root_open() at vdev_root_open+0x86
vdev_open() at vdev_open+0xa8
spa_load() at spa_load+0x1d0
spa_load() at spa_load+0x452
spa_open_common() at spa_open_common+0x12d
spa_get_stats() at spa_get_stats+0x42
zfs_ioc_pool_stats() at zfs_ioc_pool_stats+0x2c
zfsdev_ioctl() at zfsdev_ioctl+0x8d
devfs_ioctl_f() at devfs_ioctl_f+0x77
kern_ioctl() at kern_ioctl+0xf6
ioctl() at ioctl+0xfd
syscall() at syscall+0x246
Xfast_syscall() at Xfast_syscall+0xe1
--- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800fe874c, rsp = 0x7fffffffd808,                                                                              rbp = 0x80122d440 ---
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2010-04-03 00:47:41 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-fs

Over to maintainer(s).
Comment 2 Antonios Anastasiadis 2010-07-02 08:15:29 UTC
This crash also occurs in 8.1-RC2 to me.
Comment 3 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:01:00 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped