On Sun, Jan 27, 2008 at 10:40:11PM +0100, Reinoud Zandijk wrote: > Dear folks, > > On Sat, Jan 26, 2008 at 05:57:50PM +0000, Andrew Doran wrote: > > > 3) I think it'd be nice if we could retain something akin to > > > lockmgr_printinfo(). I realize that our locking is now such that we need > > > to print more than just one big heavy lock. However being able to figure > > > out what's up/broken with locks can help. :-) > > > > We have 'show lock' from ddb. I'll see about providing a replacement. > Debugging on deadlock detection then becomes printing out the locks and > their claim and release points. > > Could a kmutex be given a kind of `timeout' value? i.e. if it hasn't been > exited after the specified time it is considered a deadlock? Say a minute > or so as default? > > comments? Do all of the places that try to lock a kmutex always check return values? The older locking primitives, such as vnode locks, often were called in places that didn't cope with getting a return error code. Many times that means they didn't bother to check. :-) While you're probably right that something's wrong if we spend a minute waiting for a mutex, I'm not sure what we can do about it. I think we'll run into problems just adding deadlock detection/resolution externally; the code that grabs the locks needs to be able to cope with retry/deadlock handling. Take care, Bill
Attachment:
pgp12ff0Udkm7.pgp
Description: PGP signature