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
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
Hi,
If I give binmiscctl the magic for arm6 and then for say mips64, will
this break things?
Let's say I'm using an amd64 box to cross-compile using poudriere
for arm6 and mips64 ports. Can I do both on the same box at the same time?
Or do I need to let's say the arm6 run to finish, then give b
Hi!
> If I give binmiscctl the magic for arm6 and then for say mips64, will
> this break things?
>
> Let's say I'm using an amd64 box to cross-compile using poudriere
> for arm6 and mips64 ports. Can I do both on the same box at the same
> time? Or do I need to let's say the arm6 run to finish, t
On Mon, Mar 04, 2019 at 06:53:01PM +0100, Kurt Jaeger wrote:
Hi!
If I give binmiscctl the magic for arm6 and then for say mips64, will
this break things?
Let's say I'm using an amd64 box to cross-compile using poudriere
for arm6 and mips64 ports. Can I do both on the same box at the same
time?
On Mon, Mar 4, 2019 at 11:50 AM tech-lists wrote:
>
> Hi,
>
> If I give binmiscctl the magic for arm6 and then for say mips64, will
> this break things?
>
> Let's say I'm using an amd64 box to cross-compile using poudriere
> for arm6 and mips64 ports. Can I do both on the same box at the same time
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
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 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 =
