panic "Sleeping thread owns a non-sleepable lock" via cv_timedwait_signal, was "rsync over NFS"

Rick Macklem rmacklem at uoguelph.ca
Tue Oct 2 21:46:43 UTC 2012


John Baldwin wrote:
> On Tuesday, October 02, 2012 2:19:35 pm Norbert Aschendorff wrote:
> > Well...
> >
> > Here the results for a kernel without WITNESS_SKIPSPIN (I'll compile
> > one
> > including that tomorrow, but until then...)
> >
> > Good news is: The kernel crashed with activated WITNESS.
> > Bad news is: I have to turn power off after the crash with WITNESS.
> > The
> > crash dump is _not_ written to disk :(
> >
> > Good news II is: It wrote something to the syslog. Actually, it
> > wrote
> > very much to the syslog, some megabytes in total. Most of it is the
> > same, here the latest messages logfile:
> > http://lbo.spheniscida.de/Files/nfs-crash.log (94K)
> >
> > It specifies the file, line and zone. Maybe it's useful...
> 
> That does help. It tells us that the lock being held is a vnode
> interlock
> that was last acquired in vinactive().
> 
> I don't see how though, unless the lock was recursively acquired
> elsewhere.
> 
Yep, it looks like every call to vinactive() is followed by a VI_UNLOCK().
Also, when v_interlock gets mtx_init()'d, it only gets MTX_DEF, so I think
there would be a panic() if VI_LOCK(vp) was done recursively?

I've added kib@ to the cc list, in case he has some insight into this?
(Kostik, Norbert gets a panic() after "Sleeping thread (tid nn, pid mm) owns
 a non-sleepable lock" happens in propagate_priority() called from cv_timedwait_sig()
 in the server side krpc by a kernel nfsd thread.)

rick
> You could try adding a different WITNESS check (using WITNESS_WARN) to
> see
> which NFS proc returns with a lock held so you can catch this when it
> first
> occurs rather than much later after the fact. Do you have the start of
> the
> log messages?
> 
> --
> John Baldwin
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
> "freebsd-stable-unsubscribe at freebsd.org"


More information about the freebsd-stable mailing list