On Feb 3, 2012, at 5:45 PM, Emmanuel Dreyfus wrote:
Emmanuel Dreyfus m...@netbsd.org wrote:
What about adding a timeout in struct puffs_msgpark and use it for
inactive operations? Returning EAGAIN from puffs_vnop_inactive seems an
easy way to work around this deadlock.
I reply to myself.
J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote:
So this is on 5.x ?
Yes, this is on netbsd-5
For -current the getnewvnode()-getcleanvnode() path has been replaced
with a cleaner thread so getnewvnode() always gets a new vnode. This was
done to break deadlocks like this one (most time
On Feb 3, 2012, at 7:23 PM, Emmanuel Dreyfus wrote:
J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote:
So this is on 5.x ?
Yes, this is on netbsd-5
For -current the getnewvnode()-getcleanvnode() path has been replaced
with a cleaner thread so getnewvnode() always gets a new vnode. This
J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote:
kern/vfs_vnode.c rev. 1.12 and 1.13 should be sufficient -- but it needs some
testing on netbsd-5.
kern/vfs_vnode.c does not even exist on netbsd-5, I guess it means it is
not a reasonable pullup.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
On Feb 3, 2012, at 8:44 PM, Emmanuel Dreyfus wrote:
J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote:
kern/vfs_vnode.c rev. 1.12 and 1.13 should be sufficient -- but it needs some
testing on netbsd-5.
kern/vfs_vnode.c does not even exist on netbsd-5, I guess it means it is
not a
J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote:
It is called vfs_subr.c here -- you could just try a patch.
I gave it a try, but it crashes very early, with no chance of debugging
it: console is not yet usable
NetBSD 5.1_STABLE (XEN3_DOMU_PUFFS) #370: Sat Feb 4 03:21:45 CET 2012
