From owner-freebsd-scsi@FreeBSD.ORG Thu Feb 23 22:06:17 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 33604106564A; Thu, 23 Feb 2012 22:06:17 +0000 (UTC) (envelope-from Kashyap.Desai@lsi.com) Received: from na3sys009aog117.obsmtp.com (na3sys009aog117.obsmtp.com [74.125.149.242]) by mx1.freebsd.org (Postfix) with ESMTP id 138A28FC13; Thu, 23 Feb 2012 22:06:15 +0000 (UTC) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob117.postini.com ([74.125.148.12]) with SMTP ID DSNKT0a4V3VAo29DQp3KV4QFetvZ/vWwmzT5@postini.com; Thu, 23 Feb 2012 14:06:16 PST Received: from PALHUB01.lsi.com (128.94.213.114) by PALEDGE01.lsi.com (192.19.193.42) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 23 Feb 2012 17:10:52 -0500 Received: from inbexch01.lsi.com (135.36.98.37) by PALHUB01.lsi.com (128.94.213.114) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 23 Feb 2012 17:06:06 -0500 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch01.lsi.com ([135.36.98.37]) with mapi; Fri, 24 Feb 2012 03:36:03 +0530 From: "Desai, Kashyap" To: Alexander Kabaev Date: Fri, 24 Feb 2012 03:35:58 +0530 Thread-Topic: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited Thread-Index: AczyPYPQhFXJc1z1RkuTykhWCQNRMwAOR/ZA Message-ID: References: <20120223094611.GC32748@hoeg.nl> <20120223101157.0bb3f2ee@kan.dyndns.org> In-Reply-To: <20120223101157.0bb3f2ee@kan.dyndns.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ed Schouten , freebsd-stable , "joerg@FreeBSD.org" , "Kenneth D. Merry" , "freebsd-scsi@freebsd.org" , "Justin T. Gibbs" , "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: Thu, 23 Feb 2012 22:06:17 -0000 > -----Original Message----- > From: Alexander Kabaev [mailto:kabaev@gmail.com] > Sent: Thursday, February 23, 2012 8:42 PM > To: Desai, Kashyap > Cc: Ed Schouten; freebsd-stable; joerg@FreeBSD.org; Kenneth D. Merry; > freebsd-scsi@freebsd.org; Justin T. Gibbs; McConnell, Stephen > Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping > prohibited >=20 > On Thu, 23 Feb 2012 18:45:29 +0530 > "Desai, Kashyap" wrote: >=20 > > > > > > > -----Original Message----- > > > From: Ed Schouten [mailto:ed@80386.nl] > > > Sent: Thursday, February 23, 2012 3:16 PM > > > To: Desai, Kashyap > > > Cc: freebsd-scsi@freebsd.org; freebsd-stable; joerg@FreeBSD.org; > > > Kenneth D. Merry; McConnell, Stephen; Justin T. Gibbs > > > Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping > > > prohibited > > > > > > Hi Kashyap, > > > > > > * Desai, Kashyap , 20120222 18:51: > > > > Adding Ed Schouten and Jorg Wunsch as I see there are author of > > > > msleep/mtx related APIs. > > > > > > Am I? :-) > > I am new to FreeBSD and desperate to know the answer. :-). Thanks for > > your help. > > > > > > > 1. When any irq is register with FreeBSD OS, it sets " > > > > TDP_NOSLEEPING" pflag. 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. > > > > > > > > > > > > mps_dprint(sc, MPS_TRACE, "%s\n", __func__); > > > > mps_lock(sc); > > > > mps_intr_locked(data); > > > > mps_unlock(sc); > > > > > > > > I wonder why there is no issue with above code ? Theoretical we > > > > cannot sleep in ISR. (as explained in #1) Any thoughts ? > > > > > > The TDP_NOSLEEPING flag only disallows sleeping of an indeterminate > > > amount of time. Locking a mutex is allowed, as it can only cause the > > > thread to be blocked for a small amount of time, waiting for another > > > thread to unlock it. > > So does this assumption that another thread will release mutex fast > > enough ? Same as msleep() this can be applicable here as well. I mean > > another thread _can_ (if some bad drivers) take long time to release > > mutex. > > > > > Bad drivers can just defererence wild pointer to satisfy their need for > wrongdoing. For that reason let us keep them out of conversation. OK.=20 >=20 > mtx locks were designed to protect small sections of code where thread > is only allowed to block waiting for other thread to release the lock of > similar class. While threads are blocked, they get benefit of adaptive > sleep and priority propagation and should take precaution of never > taking the path of code that can cause them to sleep. Assertions are > there to help code authors with that. >=20 > sleep locks are by definition unbound. There is no spinning, no priority > propagation. Holders are free to take, say, page faults and go to long > journey to disk and back, etc. I understood your above lines. > Hardly the stuff _anyone_ would want to > do from interrupt handler, thread or otherwise. So the way mps driver does in interrupt handler is as below. mps_lock(sc); mps_intr_locked(data); mps_unlock(sc); We hold the mtx lock in Interrupt handler and do whole bunch of work(this i= s bit lengthy work) under that.=20 It looks mps driver is miss using mtx_lock. Are we ? ~ Kashyap >=20 >=20 > > > > 3. I recently added few place msleep() instead of DELAY in ISR > > > > context and I see " Trying sleep, but thread marked as sleeping > > > > prohibited". > > > > > > Which makes sense, as msleep() can be used to sleep for > > > indefinitely. > > This part is clear. ! I agree with all experts view. > > > > > > -- > > > Ed Schouten > > > WWW: http://80386.nl/ > > _______________________________________________ > > freebsd-scsi@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > > To unsubscribe, send any mail to > > "freebsd-scsi-unsubscribe@freebsd.org" >=20 >=20 > -- > Alexander Kabaev