Date: Mon, 23 Nov 2015 18:03:01 -0700 From: Alan Somers <asomers@freebsd.org> To: Mark Johnston <markj@freebsd.org> Cc: Kurt Lidl <lidl@pix.net>, FreeBSD-Current <freebsd-current@freebsd.org>, "will@freebsd.org" <will@freebsd.org> Subject: Re: New LOR in zfs? Message-ID: <CAOtMX2hcZPHzRkhcvMDxKV%2BwhEaeiuefMDfA5tv-sMQFzk79cw@mail.gmail.com> In-Reply-To: <CAMw1wOwYHGzVzWQFyPP%2BLOakvSLV0kQeEHmGyepvy3GQGGYo0g@mail.gmail.com> References: <5653798F.1060708@pix.net> <CAMw1wOwYHGzVzWQFyPP%2BLOakvSLV0kQeEHmGyepvy3GQGGYo0g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Nov 23, 2015 at 2:12 PM, Mark Johnston <markj@freebsd.org> wrote: > On Mon, Nov 23, 2015 at 12:39 PM, Kurt Lidl <lidl@pix.net> wrote: >> I installed a build of r291086 on a machine today >> (previously, the machine had been running 10/stable). >> >> I ran the following two commands just after rebooting >> with the new user-land bits: >> >> root@ton-95: df >> Filesystem 1K-blocks Used Avail Capacity Mounted on >> sys/ROOT/default 18061924 804940 17256984 4% / >> devfs 1 1 0 100% /dev >> tmpfs 65536 8 65528 0% /tmp >> sys/home 17257108 124 17256984 0% /home >> sys/local 17283924 26940 17256984 0% /usr/local >> sys/obj.4 19440624 2183640 17256984 11% /usr/obj >> sys/obj.1 19440440 2183456 17256984 11% /usr/obj.1 >> sys/obj.2 19588696 2331712 17256984 12% /usr/obj.2 >> sys/obj.3 19588636 2331652 17256984 12% /usr/obj.3 >> sys/ports 17257080 96 17256984 0% /usr/ports >> sys/src 19740468 2483484 17256984 13% /usr/src >> sys/var 17358024 101040 17256984 1% /var >> root@ton-96: zfs set mountpoint=/usr/obj.4 sys/obj.4 >> >> I got a LOR (new to me, at any rate) on the console: >> lock order reversal: >> 1st 0xfffff8000612da38 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1224 >> 2nd 0xfffff8000612d4b0 zfs_gfs (zfs_gfs) @ >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/gfs.c:494 >> stack backtrace: >> #0 0xc05b1e3c at __lockmgr_args???=?-~????+0xa3c >> #1 0xc06a9118 at vop_std???=?-~????lock+0x38 >> #2 0xc09e8164 at VOP_???=?-~????LOCK1_APV+0x104 >> #3 0xc06d125c a???=?-~????t _vn_lock+0x9c >> #4 0xc12a7b04 a???=?-~????t gfs_file_create+0x64 >> #5 0xc12???=?-~????a7c14 at gfs_dir_create+0x14 >> #6???=?-~???? 0xc139fc14 at zfsctl_mknode_sn???=?-~????apdir+0x54 >> #7 0xc12a82bc at gfs???=?-~????_dir_lookup+0x31c >> #8 0xc139f6cc???=?-~???? at zfsctl_root_lookup+0x12c >> #9???=?-~???? 0xc139f7b4 at zfsctl_umount_sn???=?-~????apshots+0x54 >> #10 0xc13bb44c at ???=?-~????zfs_umount+0x4c >> #11 0xc06b34a8 ???=?-~????at dounmount+0xbc8 >> #12 0xc06b38???=?-~????f0 at sys_unmount+0x410 >> #13 0xc???=?-~????09de004 at syscall+0x3c4 >> >> The machine in question is a sparc4u machine, but I do not think >> it matters. > > The garbled output should be fixed by r291217. This is a tough one, but Will (CC'ed) has made some progress fixing it. -Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2hcZPHzRkhcvMDxKV%2BwhEaeiuefMDfA5tv-sMQFzk79cw>