From owner-freebsd-scsi@FreeBSD.ORG Wed Feb 22 19:59:58 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 492EE106566B; Wed, 22 Feb 2012 19:59:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id CE29C8FC14; Wed, 22 Feb 2012 19:59:57 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q1MJFK1b096717; Wed, 22 Feb 2012 21:15:20 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q1MJFJqN039916; Wed, 22 Feb 2012 21:15:19 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q1MJFJGQ039915; Wed, 22 Feb 2012 21:15:19 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 22 Feb 2012 21:15:19 +0200 From: Konstantin Belousov To: "Desai, Kashyap" Message-ID: <20120222191519.GT55074@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mgIE+9cwyCTt+85Z" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: "freebsd-scsi@freebsd.org" , "Kenneth D. Merry" , "Justin T. Gibbs" , freebsd-stable , "McConnell, Stephen" Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 19:59:58 -0000 --mgIE+9cwyCTt+85Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 22, 2012 at 07:36:42PM +0530, Desai, Kashyap wrote: > Hi, >=20 > I am doing some code changes in mps dirver. While working on those change= s, I come to know about something which is new to me. > Some expert help is required to clarify my doubt. >=20 > 1. When any irq is register with FreeBSD OS, it sets " TDP_NOSLEEPING" pf= lag. It means though irq in freebsd is treated as thread, > We cannot sleep in IRQ because of " "TDP_NOSLEEPING " set. > 2. In mps driver we have below code snippet in ISR routine. >=20 >=20 > mps_dprint(sc, MPS_TRACE, "%s\n", __func__); > mps_lock(sc); > mps_intr_locked(data); > mps_unlock(sc); >=20 > I wonder why there is no issue with above code ? Theoretical we cannot sl= eep in ISR. (as explained in #1) > Any thoughts ? >=20 >=20 > 3. I recently added few place msleep() instead of DELAY in ISR context an= d I see=20 > " Trying sleep, but thread marked as sleeping prohibited". >=20 FreeBSD has several basic ways to prevent a thread from executing on CPU. They mostly fall into two categories: bounded sleep, sometimes called blocking, and unbounded sleep, usually abbreviated as sleep. The bounded there refers to amount of code executed by other thread that hold resource preventing blocked thread from making a progress. Examples of the blocking primitives are mutexes, rw locks and rm locks. The blocking is not counted as sleeping, so interrupt threads, which are designated as non-sleeping, still can lock mutexes. Examples of the sleeping primitives are msleep(), sx locks, lockmgr locks and conditional variables. In essence, the locking facilities are split into several classes that form the hierarchy, and you cannot legally obtain the lock of higher class while holding a lock of lower class: spin mutexes -> blocking locks -> sleeping locks. It establishes some meta-order on the all locks. Does this make sense ? --mgIE+9cwyCTt+85Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9FPsYACgkQC3+MBN1Mb4jg3wCeLVn0cKBcNva+KW7kkXym2wQf MIUAoNvRwD93Sxnykix6rw/vR+lmSa0z =IYv+ -----END PGP SIGNATURE----- --mgIE+9cwyCTt+85Z--