Date: Sat, 12 Feb 2011 19:01:12 +0000 From: Nik A Azam <freebsd-list@nikazam.com> To: freebsd-fs@freebsd.org, mm@freebsd.org Subject: Re: New ZFSv28 patchset for 8-STABLE Message-ID: <AANLkTimChDiRGGieuPzJ_b7LwGFr-gF5bVJfDfwYtPQ=@mail.gmail.com> In-Reply-To: <AANLkTi=Q1mJWU7tFsEtraO8WusPmJvY=m9=1KT5QVS=J@mail.gmail.com> References: <4D0A09AF.3040005@FreeBSD.org> <4D46D0CF.8090103@chreo.net> <AANLkTi=Q1mJWU7tFsEtraO8WusPmJvY=m9=1KT5QVS=J@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ok, looking at SVN log there was a change to vdev_geom.c recently after mm's patch. I synced to revision r218540 and all is good. Sorry for the noise! nik On Sat, Feb 12, 2011 at 9:54 AM, Nik A Azam <freebsd-list@nikazam.com>wrote: > Hi Martin, all > > I'm testing the ZFS v28 on FreeBSD stable (r218583M , ZFS patch from > http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20110208-nopython.patch.xz) > and been getting this panic everytime I issue any zfs/zpool command. This is > 100% reproducible. > > panic: _sx_xlock_hard: recursed on non-recursive sx GEOM topology @ > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c:380 > > > cpuid = 1 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > kdb_backtrace() at kdb_backtrace+0x37 > panic() at panic+0x182 > _sx_xunlock_hard() at _sx_xunlock_hard > _sx_xlock() at _sx_xlock+0xa9 > vdev_geom_open_by_path() at vdev_geom_open_by_path+0x45 > vdev_geom_open() at vdev_geom_open+0x100 > vdeev_open() at vdeev_open+0xc9 > vdev_open_children() at vdev_open_children+0x39 > vdev_raidz_open() at vdev_raidz_open+0x4f > vdev_open() at vdev_open+0xc9 > vdev_open_children() at vdev_open_children+0x39 > vdev_root_open() at vdev_root_open+0x40 > vdev_open() at den)open+0xc9 > spa_load() at spa_load+0x23f > spa_load_best() at spa_load_best+0x4a > pool_status_check() at pool_status_check+0x19 > zfsdev_ioctl() at zfsdev_ioctl+0x208 > devfs_ioctl_f() at devfs_ioctl_f+0x73 > kern_ioctl() at kern_ioctl+0x8b > ioctl() at 90ctl+0xec > syscall() at syscall+0x41 > Xfast_syscall() at Xfast_syscall+0x2e > > I'm more than happy to investigate this further given instructions on how > to do so. Really appreciate the work that you guys have put in FreeBSD/ZFS! > > Thanks, > Nik > > > On Mon, Jan 31, 2011 at 3:10 PM, Chreo <chreo@chreo.net> wrote: > >> Hello Martin, >> >> On 2010-12-16 13:44, Martin Matuska wrote: >> >>> Following the announcement of Pawel Jakub Dawidek (pjd@FreeBSD.org) I am >>> providing a ZFSv28 testing patch for 8-STABLE. >>> >>> Link to the patch: >>> >>> >>> http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20101215.patch.xz >>> >>> >> I've tested >> http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20110116-nopython.patch.xz >> with 8-STABLE from 2011-01-18 >> >> Seems to work nicely except for a panic when importing a degraded pool on >> GELI vdevs: >> (captured from the screen and OCR'd) >> vdev.geom_detach:156[1]: Closing access to label/Disk.4.eli. >> vdev.geom_detach:160[1]: Destroyed consumer to label/Disk.4.eli. >> vdev.geomdetach:156[1]: Closing access to label/Disk.5.eli. >> vdev.geom_detach:160[1]: Destroyed consumer to label/Disk.5.eli. >> Solaris: WARNING: can't open objset for Ocean/Images >> panic: solaris assert: bpobj_iterate(defer_bpo, spa_free_sync_cb, zio, tx) >> == 0 (0x6 == 0x0), file: >> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c, >> line: 5576 >> cpuid = 1 >> KDB: stack backtrace: >> #0 0xffffffff802f14ce at kdb_backtrace+0x5e >> #1 0xffffffff802bf877 at panic+Ox187 >> #2 0xffffffff808e0c48 at spa_sync+0x978 >> #3 0xffffffff808f1011 at txg_sync_thread+0x271 >> #4 0xffffffff802960b7 at fork_exit+0x117 >> #5 0xffffffff804b7a7e at fork_trampoline+0xe >> GEOM_ELI: Device label/Disk.5.eli destroyed. >> GEOM_ELI: Device label/Disk.4.eli destroyed. >> >> The command run was: >> # zpool import -F Ocean >> and that worked with ZFS v15 >> >> The panic is 100% reproducible. The reason for this import was that I >> wanted to try and clear the log (something which is possible on v28 but not >> v15 it seems) with: zpool clear Ocean, and that caused a panic. An export >> was done and the import was tried. Using the same command on v15 works and >> imports the pool but it is faulted (due to the log). >> >> Anything I can test or do about this? I've also tried importing with -o >> failmode=continue and that does absolutely nothing to prevent the panic. >> >> The other pool on the same system works perfectly so far with v28. Many >> thanks to you and PJD for your work on ZFS. >> >> Regards, >> Christian Elmerot >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >> > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimChDiRGGieuPzJ_b7LwGFr-gF5bVJfDfwYtPQ=>