On Mon, Mar 4, 2019 at 5:29 PM Andriy Gapon wrote:
> On 04/03/2019 22:35, Nick Rogers wrote:
> > v_lock = {lock_object = {lo_name =
> > 0x8144af45 "zfs", lo_flags = 117112840, lo_data = 0, lo_witness =
> > 0x0}, lk_lock = 18446744073709551605, lk_exslpfail = 0, lk_timo = 51,
> > lk_pri =
On 04/03/2019 22:35, Nick Rogers wrote:
> v_lock = {lock_object = {lo_name =
> 0x8144af45 "zfs", lo_flags = 117112840, lo_data = 0, lo_witness =
> 0x0}, lk_lock = 18446744073709551605, lk_exslpfail = 0, lk_timo = 51,
> lk_pri = 96}
Hmm, lk_lock looks bogus.
18446744073709551605 == 0xff
On Sat, Mar 2, 2019 at 12:48 PM Andriy Gapon wrote:
> On 01/03/2019 17:00, Nick Rogers wrote:
> > 36704 101146 perl- mi_switch+0xe1
> > sleepq_wait+0x2c sleeplk+0x1c5 lockmgr_xlock_hard+0x19c
> VOP_LOCK1_APV+0x7e
> > _vn_lock+0x40 zfs_znode_alloc+0x434 zfs_mknode
Thanks for the insight, it does appear that in all instances of this
problem there is always one thread stuck on zfs_znode_alloc. Unfortunately
its always a different application (e.g., perl, sh, postgres). I will post
more information in the bug.
On Sat, Mar 2, 2019 at 12:48 PM Andriy Gapon wrot
On Sat, Mar 2, 2019 at 5:27 PM Peter Avalos via freebsd-stable <
freebsd-stable@freebsd.org> wrote:
>
> > On Mar 1, 2019, at 7:00 AM, Nick Rogers wrote:
> >
> > I am hoping someone can help me figure out if this is a legitimate bug,
> or
> > something already fixed in 12-STABLE. I wish I could re
> On Mar 1, 2019, at 7:00 AM, Nick Rogers wrote:
>
> I am hoping someone can help me figure out if this is a legitimate bug, or
> something already fixed in 12-STABLE. I wish I could reproduce it reliably
> to try against STABLE, but there doesn't appear to be any related ZFS fixes
> not in RELE
On 01/03/2019 17:00, Nick Rogers wrote:
> 36704 101146 perl- mi_switch+0xe1
> sleepq_wait+0x2c sleeplk+0x1c5 lockmgr_xlock_hard+0x19c VOP_LOCK1_APV+0x7e
> _vn_lock+0x40 zfs_znode_alloc+0x434 zfs_mknode+0xa9d
> zfs_freebsd_create+0x512 VOP_CREATE_APV+0x78 vn_open_cr
