From owner-freebsd-questions@FreeBSD.ORG Tue Jul 15 19:48:13 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A4A8106564A for ; Tue, 15 Jul 2008 19:48:13 +0000 (UTC) (envelope-from yonyossef.lists@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 197C08FC24 for ; Tue, 15 Jul 2008 19:48:12 +0000 (UTC) (envelope-from yonyossef.lists@gmail.com) Received: by qw-out-2122.google.com with SMTP id 9so217856qwb.7 for ; Tue, 15 Jul 2008 12:48:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=lDaSPHXfM+EHBzHUrYbjzfUuaReqd0mQBdtbqxVw0Lk=; b=pRCsi67Ur4iNUnWWj2jFJ9zhnAi1nos7jTN8xqbFwWgIhPYAju11ayoYk4+UcUkQOG gCAxKJySJCZX5RzRR/KY7BIVlgGmknRkIpOCAW6ldV9dt3eIMIJduaE8FgM4VGHKjsWn UjlXGJBWEPZS54nayqFu6RxseFAOqhZW3RmT4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=uesmPckKUW4FKYkicemiE7OdttgIXBHoQvEiIspTNsZIC+AEIOR1Uw1sGfKcUR22Oj vQiC8N2F69CXO1xGggSq8fIWeHKjQNHeUMVgOf+JJ+U1yQJjalNj3bo2pfIDa8zBwGSZ Zj/Xxn6FojMQP78PphCAJpgFRoJAYR+uXFmss= Received: by 10.151.98.16 with SMTP id a16mr803841ybm.202.1216151292326; Tue, 15 Jul 2008 12:48:12 -0700 (PDT) Received: by 10.151.84.2 with HTTP; Tue, 15 Jul 2008 12:48:12 -0700 (PDT) Message-ID: <20def4870807151248s690fd0d2s91f5afbf91d878f9@mail.gmail.com> Date: Tue, 15 Jul 2008 22:48:12 +0300 From: "Yony Yossef" To: "Kris Kennaway" In-Reply-To: <487CB0AA.3040504@FreeBSD.org> MIME-Version: 1.0 References: <20def4870807140902y4e5aad69r649d577fb5f5ad84@mail.gmail.com> <487BE91E.1020202@FreeBSD.org> <20def4870807150605w6e3de82eq4a999360e9b49b6c@mail.gmail.com> <487CA8DC.2090703@FreeBSD.org> <20def4870807150656y761a8bcfo858b85b760d0f93f@mail.gmail.com> <487CB0AA.3040504@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-questions@freebsd.org Subject: Re: options WITNESS and locks X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2008 19:48:13 -0000 Problem solved :-) Thank you very much for your patience Kris.. On Tue, Jul 15, 2008 at 5:14 PM, Kris Kennaway wrote: > Yony Yossef wrote: > >> >> Something is still unclear. All my locks are MTX_DEF type, which >> means >> sleepable, including the one specified in the crash report >> (MTNIC state >> semaphore). >> This crash happens when I try to call bus_resource_alloc_any for >> a SYS_REQ >> which is trying to obtain the second lock (ACPI root bus). How >> come my >> MTX_DEF lock is being treated as as non-sleepable? >> >> >> MTX_DEF locks *are* non-sleepable :-) >> >> Kris >> >> Good news :-) >> Yet the documentation is confusing me: >> man pages say: >> MTX_DEF Default mutexes will always allow the current thread to be >> suspended to avoid deadlock conditions against >> interrupt >> threads. The implementation of this lock type may spin >> for a while before suspending the current thread. >> and in mutex.h: >> /* >> * Mutex types and options passed to mtx_init(). MTX_QUIET and MTX_DUPOK >> * can also be passed in. >> */ >> #define MTX_DEF 0x00000000 /* DEFAULT (sleep) lock */ >> #define MTX_SPIN 0x00000001 /* Spin lock (disables interrupts) */ >> #define MTX_RECURSE 0x00000004 /* Option: lock allowed to recurse */ >> #define MTX_NOWITNESS 0x00000008 /* Don't do any witness checking. */ >> #define MTX_NOPROFILE 0x00000020 /* Don't profile this lock */ >> What does the "DEFAULT (sleep) lock" comment near MTX_DEF means? >> And which ones are sleepable?.. I guess I'm missing something here. >> > > "sleep mutex" means that the mutex holder may be put to sleep by the kernel > while the mutex is held by another process (if the lock holder is running > then it will spin, though). It is in contrast to "spin" mutexes that always > spin forever while the lock is held, even when it might be inefficient for > them to do so because the lock holder is no longer running after the CPU > context switched to another process before it released the lock. > > This describes the behaviour of the mutex while it is waiting to acquire a > lock. > > "sleepable" vs "non-sleepable" locks means what it is legal for your code > to do while holding a mutex and doesn't relate to the internal > implementation of the lock. > > This describes what it is legal for your code to do once it has acquired > the lock. > > Kris > >