Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 19 Jan 2002 11:48:48 -0800
From:      Alfred Perlstein <bright@mu.org>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        smp@FreeBSD.ORG
Subject:   Re: help with mutex_pool please?
Message-ID:  <20020119114848.A13686@elvis.mu.org>
In-Reply-To: <200201191942.g0JJgLK50974@apollo.backplane.com>; from dillon@apollo.backplane.com on Sat, Jan 19, 2002 at 11:42:21AM -0800
References:  <20020119080125.X13686@elvis.mu.org> <200201191942.g0JJgLK50974@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
* Matthew Dillon <dillon@apollo.backplane.com> [020119 11:42] wrote:
> :
> :I was going to convert some subsystems to use mutex pools...
> :
> :However if I apply this delta, a couple of seconds after boot I get
> :a lockup, sometimes the panic message is printed "sleeping with
> :mutex held"
> :
> :Any clues?
> 
>     I don't see anything obviously wrong.  Can you get a backtrace
>     from where it panic'd?

No, it locks hard.  What I can do is see if it's either uidinfo or
file locking that's causing it (or both) and get back to you.  That
is unless you want to take a shot at it.

Perhaps you can suggest some debugging KTR/printfs to be added to the
subsystem?

Btw, mtx_pool_lock is sort of misleading, I thought it meant "lock
a pool mutex", but it really means lock the pool containing the
mutex.  Maybe mtx_pool_lock/unlock shouldn't take void *, they
should take a "struct mutex_pool *" or something and make the caller
explicitly do the mutex_pool_find?

-- 
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
 start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020119114848.A13686>