Date: Wed, 22 Feb 2012 21:15:19 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: "Desai, Kashyap" <Kashyap.Desai@lsi.com> Cc: "freebsd-scsi@freebsd.org" <freebsd-scsi@freebsd.org>, "Kenneth D. Merry" <ken@freebsd.org>, "Justin T. Gibbs" <gibbs@freebsd.org>, freebsd-stable <freebsd-stable@freebsd.org>, "McConnell, Stephen" <Stephen.McConnell@lsi.com> Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited Message-ID: <20120222191519.GT55074@deviant.kiev.zoral.com.ua> In-Reply-To: <B2FD678A64EAAD45B089B123FDFC3ED72B96D34836@inbmail01.lsi.com> References: <B2FD678A64EAAD45B089B123FDFC3ED72B96D34836@inbmail01.lsi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120222191519.GT55074>