Looks like same stack as 6413847, although it is pointed more towards hardware failure.
the stack below is from 5.11 snv_38, but also seems to affect update 2 as per above bug.
Enda
Thomas Maier-Komor wrote:
Hi, my colleage is just testing ZFS and created a zpool which had a backing store file on a TMPFS filesystem. After deleting the file everything still worked normally. But destroying the pool caused an assertion failure and a panic. I know this is neither a real-live szenario nor a good idea. The assertion failure occured on Solaris 10 update 2.Below is some mdb output, in case someone is interested in this. BTW: great to have Solaris 10 update 2 with ZFS. I can't wait to deploy it. Cheers, Tom::panicinfocpu 1 thread 2a100ea7cc0 message assertion failed: vdev_config_sync(rvd, txg) == 0, file: ../../common/fs/zfs/spa .c, line: 2149 tstate 4480001601 g1 30037505c40 g2 10 g3 2 g4 2 g5 3 g6 16 g7 2a100ea7cc0 o0 11eb1e8 o1 2a100ea7928 o2 3000006f5b0 o3 30037505c50 o4 30000c7a000 o5 15 o6 2a100ea6ff1 o7 105e560 pc 104220c npc 1042210 y 10::stackvpanic(11eb1e8, 13f01d8, 13f01f8, 865, 600026d4ef0, 60002793ac0) assfail+0x7c(13f01d8, 13f01f8, 865, 183e000, 11eb000, 0) spa_sync+0x190(60001f244c0, 3dd9, 600047f3500, 0, 2a100ea7cc4, 2a100ea7cbc) txg_sync_thread+0x130(60001f9c580, 3dd9, 2a100ea7ab0, 60001f9c6a0, 60001f9c692, 60001f9c690) thread_start+4(60001f9c580, 0, 0, 0, 0, 0)::statusdebugging crash dump vmcore.0 (64-bit) from ai operating system: 5.11 snv_38 (sun4u) panic message: assertion failed: vdev_config_sync(rvd, txg) == 0, file: ../../common/fs/zfs/spa .c, line: 2149 dump content: kernel pages only This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss