<p dir="ltr"><br>
On Jun 7, 2016 4:52 AM, "Daniel Wagner" <<a href="mailto:wagi@monom.org">wagi@monom.org</a>> wrote:<br>
><br>
> >> I try to reproduce it on 4.6. My steps do not always trigger the crash.<br>
> >> So I can't be really sure if 4.6 doesn't show it, it does not happen.<br>
> ><br>
> > I have never been able to trigger this in 4.6 and it's my failsafe<br>
> > reboot (4.6.0).<br>
> > In 4.7-rc1 it's just a matter of time before I hit it.<br>
> > I do a lot of transactions, using git, extraction of tar.xz etc normally.<br>
><br>
> This rings a bell. I though the lockperf tests triggered it. Before I<br>
> compiled a new kernel I did a 'git checkout' step.</p>
<p dir="ltr">Yeah, could well be. During big git operations I get into this and while I was trying to compile GCC 6.1.0 and I was moving mpfc dir into gcc/mpfc for example. The move never completed. I do use git to get the latest kernel sources for wireless testing. With the 4.6.0 I didn't hit problems. Ever since I started using 4.7 I kept crashing on asserts in xfs. :) As I hit this frequently I can instrument. I did write some instrumentation to display the args flags before the assert, but from Eric's work, it doesn't seem these are important at all as it might be a locking issue. I will say that it sounds most likely a locking issue to me , because sometimes I just hang in an fs operation and it never completes. Even trying to kill the mv operation doesn't work. I can try to reproduce tomorrow and either reach the assert or get stuck in a lock in which case trace-cmd might help.<br>
Thanks,</p>
<p dir="ltr">Reinoud.<br>
</p>