booted in single user mode.
two seconds... then... boom:
KDB: stack backtrace:
#0 0xffffffff8096eec0 at kdb_backtrace+0x60
#1 0xffffffff80933b95 at panic+0x155
#2 0xffffffff80d66c1f at trap_fatal+0x38f
#3 0xffffffff80d66f38 at trap_pfault+0x308
#4 0xffffffff80d6659a at trap+0x47a
#5 0xffffffff80d4c482 at calltrap+0x8
#6 0xffffffff819e8a9c at dmu_write_uio_dnode+0xcc
#7 0xffffffff819e89ab at dmu_write_uio_dbuf+0x3b
#8 0xffffffff81a7a5b2 at zfs_freebsd_write+0x5e2
#9 0xffffffff80e85c35 at VOP_WRITE_APV+0x145
#10 0xffffffff809e37e9 at vn_rdwr+0x299
#11 0xffffffff81a36e55 at vdev_file_io_start+0x165
#12 0xffffffff81a54676 at zio_vdev_io_start+0x326
#13 0xffffffff81a51382 at zio_execute+0x162
#14 0xffffffff81a84e9e at trim_map_commit+0x2ae
#15 0xffffffff81a84ce7 at trim_map_commit+0xf7
#16 0xffffffff81a84ce7 at trim_map_commit+0xf7
#17 0xffffffff81a84a32 at trim_thread+0xf2
I added vfs.zfs.trim.enabled=0 to /boot/loader.conf and it boots nicely.
It is an HP DL360 with ciss0: <HP Smart Array P410i>. Just a single volume presented to the OS, so it is not JBOD, and there are no SSD disks involved.
This looks like is the same issue as noted on:
Didn't notice that you're mounting a file backed volume not geom backed at the time.
File backed volume? No, it uses gpt partitions?
# zpool history
History for 'tank':
2013-02-25.14:56:06 zpool create -f -o altroot=/mnt -o cachefile=/var/tmp/zpool.cache tank /dev/gpt/disk0.nop
2013-02-25.14:56:22 zpool export tank
2013-02-25.14:58:23 zpool import -o altroot=/mnt -o cachefile=/var/tmp/zpool.cache tank
2013-02-25.15:00:15 zpool set bootfs=tank tank
It is a zfs-on-root setup, probably setup according to the guidelines of https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/9.0-RELEASE
(In reply to Palle Girgensohn from comment #2)
> File backed volume? No, it uses gpt partitions?
> # zpool history
> History for 'tank':
> 2013-02-25.14:56:06 zpool create -f -o altroot=/mnt -o
> cachefile=/var/tmp/zpool.cache tank /dev/gpt/disk0.nop
> 2013-02-25.14:56:22 zpool export tank
> 2013-02-25.14:58:23 zpool import -o altroot=/mnt -o
> cachefile=/var/tmp/zpool.cache tank
> 2013-02-25.15:00:15 zpool set bootfs=tank tank
> It is a zfs-on-root setup, probably setup according to the guidelines of
Your trace disagrees as it mentions vdev_file_io_start which is only called for a volume created from a file if it was gpt that would be vdev_geom_io_start.
Can you let us know your pool layout with zdb please.
Ah, OK... Haha... Just realized, my collegue has apparently set up a test pool, that one is indeed from files. OK, your absolutely right, it is file based.
# zdb -C testpool
There are actually two pools here.
tank and testpool
tank is from a gpart device
testpool is from two files in a zfs file system within tank. A bit odd as a setup, but as the name reveals, it is just a testpool that was never properly cleaned up.
Thanks for confirming. Did you get chance to test the patch and does it fix the issue for you?
This was fixed by https://svnweb.freebsd.org/base?view=revision&revision=274619
Commit hook didn't trigger to note this for some reason.
*** This bug has been marked as a duplicate of bug 195061 ***