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

Konstantin Belousov kostikbel at gmail.com
Wed Oct 3 15:54:58 UTC 2012


On Wed, Oct 03, 2012 at 09:24:11AM -0400, Rick Macklem wrote:
> Norbert Aschendorff wrote:
> > Another logs - even with a /var/crash crash report :)
> > 
> > Please note: The /var/crash files stem from another crash than the big
> > syslog does!
> > 
> > The syslog file inside the tarball is about 4.7 MB; it contains
> > everything since the start of the crash.
> > 
> > New /var/crash files:
> > http://lbo.spheniscida.de/Files/nfs-rsync-crash-witnessII.tgz
> > New syslog file:
> > http://lbo.spheniscida.de/Files/nfs-rsync-crash-witnessIII-only-messages.tgz
> > 
> > (Both < 100 KB)
> > 
> > The used kernel is called GENERIC-OWN-WITNESS and has all three
> > WITNESS
> > options enabled and nothing else.
> > 
> I'll take a look at these later to-day.
> 
> > But I just get an idea: Should I try it without Rick's NFSv4
> > numeric-uid-gid patch? Or is that completely unrelated?
> > @Rick: Can you assure that it is impossible that the patch added this
> > bug?
> Doesn't seem likely, but I'd never guarantee that a patch isn't broken
> and/or can never have weird side effects. So, it might be worth trying
> backing the patch out and seeing if it still crashes.
> 
> Thanks for doing this testing, rick

So do you use nullfs exported mounts ? And stable ?
Can you try to remove nullfs from the set up ?

I wonder if there are any calls to VFS_FHTOVP() with LK_INTERLOCK set.
Specifically, nullfs probably does not handle LK_INTERLOCK properly both
for nullfs_vget and nullfs_fhtovp() at all.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20121003/9ac66429/attachment.pgp


More information about the freebsd-stable mailing list