> Are you sure this isn't a case of CR 6433264 which > was fixed > long ago, but arrived in patch 118833-36 to Solaris > 10?
It certainly looks similar, but this system already had 118833-36 when the error occurred, so if this bug is truly fixed, it must be something else. Then again, I wasn't adding spares, I was adding a raidz1 group, so maybe it was patched for adding spares but not other vdevs. I looked at the bug ID but couldn't tell if there was a simple test I could perform to determine if this was the same or a related bug, or something completely new. The error message is the same, except for the reported line number. Here's some mdb output similar to what was in the original bug report: r...@kronos:/ # mdb core Loading modules: [ libumem.so.1 libnvpair.so.1 libuutil.so.1 libc.so.1 libavl.so.1 libsysevent.so.1 ld.so.1 ] > $c libc.so.1`_lwp_kill+8(6, 0, ff1c3058, ff12bed8, ffffffff, 6) libc.so.1`abort+0x110(ffbfb760, 1, 0, fcba0, ff1c13d8, 0) libc.so.1`_assert+0x64(213a8, 213d8, 277, 8d990, fc8bc, 32008) 0x1afe8(11, 0, 1a2d78, dff40, 16f2a400, 4) 0x1b028(8df60, 8cfd0, 0, 0, 0, 4) make_root_vdev+0x9c(abe48, 0, 1, 0, 8df60, 8cfd0) 0x1342c(8, abe48, 0, 7, 0, ffbffdca) main+0x154(9, ffbffce4, 9, 3, 33400, ffbffdc6) _start+0x108(0, 0, 0, 0, 0, 0) I'm happy to further poke at the core file or provide other data if anyone's interested... -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
