On Sun, Jun 24, 2018 at 08:18:17PM +0200, Walter Alejandro Iglesias wrote:
> Hi Visa,
>
> On Sun, Jun 24, 2018 at 05:54:15PM +0000, Visa Hankala wrote:
> > On Sun, Jun 24, 2018 at 12:37:45PM +0200, Walter Alejandro Iglesias wrote:
> > > panic: mtx 0xffffffff81c86470: locking against myself
> > > Stopped at db_enter+0x12: popq %r11
> > > TID PID UID PRFLAGS PFLAGS CPU COMMAND
> > > 104021 96401 1000 0x3 0x4000000 2 mpv
> > > *402610 50624 1000 0x32 0 0K Xorg
> > >
> > > db_enter() at db_enter+0x12
> > > panic() at panic+0x138
> > > __mtx_enter_try(53b9235709d40154) at __mtx_enter_try+0xb5
> > > _mtx_enter(ffffffff81cf3e60,ffffffff81a5d6a2,0) at _mtx_enter+0x5a
> > > printf(c9ef1007dec621e0) at printf+0x70
> > > witness_checkorder(2e4447d1b3cbb9af,ffffffff81c2ac7c,32a,0,ffffffff81da6d00)
> > > at
> > > witness_checkorder+0x943
> > > ___mp_lock(ffff8000330cd760,d,7) at ___mp_lock+0x70
> > > selwakeup(e80faaebded7c1a2) at selwakeup+0x9c
> > > ptsstart(8ce5939828d5e23) at ptsstart+0x79
> > > tputchar(174549bf676e909c,ffff800000afa400) at tputchar+0x85
> > > kputchar(75d50501b895e9e4,0,ffffffff81a5d6a2) at kputchar+0x91
> > > kprintf() at kprintf+0xe8
> > > printf(c9ef1007dec621e0) at printf+0x85
> > > witness_checkorder(2e4447d1b3cba2fe,ffffffff81af9df1,298,ffffffff81c8a678,ffffff
> > > ff81c8a688) at witness_checkorder+0x943
> > > end trace frame: 0xffff80003302e978, count: 0
> >
> > If the panic happens again, please run the following commands in ddb(4)
> > and post the output:
> >
> > show locks
> > show all locks
>
> The true is it happend twice. On the first one fsck(8) couldn't recover
> my root file system. After rebooting I couldn't even log in (as user or
> root) and I had to reinstall. That's way I'm not confident about
> "voluntary" reproducing the bug. :-) But if it happens again take for
> sure I'll send you the output of those commands (and per cpu traces).
>
> >
> > It is not clear from the stack trace why the system begins to report
> > a lock order problem in the first place (the first witness_checkorder
> > and the printf at the end of the stack trace).
> >
> > The panic itself is related to the problem of using other kernel
> > subsystems from WITNESS. I will try to make a fix that should prevent
> > the panic in most cases.
>
>
Another thing I should've mentioned is I've been doing *heavy* use of
mpv every day since a long time without problems. That means this issue
is probably a bug introduced by some kernel modification in 20 June
snapshot or around.
Walter
