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


Hi.

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.

Thanks.
Eugene.


More information about the freebsd-stable mailing list