I'm not David, but:
I would also suggest tcpdumping to a file the nfs traffic, on some other
machine (perhaps the osx box) and then when the panic happens look at
the last few transactions to see if you spot anything odd.
There's a cache of name translations (used for namei), maintained by
Hubert Feyrer hub...@feyrer.de wrote:
The setup of this is NetBSD-current/i386 in VMware Fusion with sources
mounted via NFS from a Mac OS X NFS server.
FWIW, I had many panics on a netbsd-5/i386 NFS server with MacOS X
clients. It ran fine the day I removed the mac clients (it was still
The vnode locking requirement currently allows to call VOP_GETATTR()
on an unlocked vnode. This is orthogonal to all other operations that
read data or metadata and want at least a shared lock. It also asks
for trouble as the attributes may change while the operation is in
progress.
With the
J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote:
With the attached diff the locking protocol requests at least a shared
lock and all calls to VOP_GETATTR() outside of file systems respect it.
Please look at pn_sizemtx in src/fs/puffs/puffs_vnop.c
As I understand your change allows to remove
On Oct 9, 2011, at 5:02 PM, Emmanuel Dreyfus wrote:
J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote:
With the attached diff the locking protocol requests at least a shared
lock and all calls to VOP_GETATTR() outside of file systems respect it.
Please look at pn_sizemtx in
