VOP_WRITE <hex> is not exclusive locked but should be
Eugene M. Zheganin
emz at norma.perm.ru
Mon Feb 6 19:01:06 UTC 2012
I have a server with an 8.2-RELEASE/amd64.
It's primary use for routing/ipsec+gre tunneling. It's also running zfs.
Sometimes it's locking up: it stops to respond to the network, but the
console is still alive, though it doesn't log me in - the 'password:'
prompt never comes up (I only can type my username or enter key).
I've built a kernel with DEBUG_LOCKS/DEBUG_VFS_LOCKS, KDB/DDB,
INVARIANTS, WITNESS and stuff.
The only problem is that when booting such a new kernel and
DEBUG_LOCKS/DEBUG_VFS_LOCKS are present, I get
VOP_PUTPAGES: <hex> is not exclusive locked but should be
and the kernel immidiately enters ddb. This happens on a daemons startup
after the kernel is boot up and filesystems are mounted.
Is this something that is safe to ignore (then how do I ignore that ?
'continue' only makes a new VOP_PUTPAGES message appear) ? Is it
something that can lock up my server later on and should I report that ?
I saw similar message (only it was about VOP_WRITE) in this maillist
about 7-STABLE, someone said to try a memtest. I did one pass of a
memtest (I know this isn't enough, but I cannot run it there for a day,
and, furthermore, I got this message in subject immidiately on multiuser
boot sequence so my guess is - the errors should appear immidiately too)
and it didn't find any errors.
More information about the freebsd-stable