Date: Fri, 24 Feb 2012 03:35:58 +0530 From: "Desai, Kashyap" <Kashyap.Desai@lsi.com> To: Alexander Kabaev <kabaev@gmail.com> Cc: Ed Schouten <ed@80386.nl>, freebsd-stable <freebsd-stable@freebsd.org>, "joerg@FreeBSD.org" <joerg@FreeBSD.org>, "Kenneth D. Merry" <ken@freebsd.org>, "freebsd-scsi@freebsd.org" <freebsd-scsi@freebsd.org>, "Justin T. Gibbs" <gibbs@freebsd.org>, "McConnell, Stephen" <Stephen.McConnell@lsi.com> Subject: RE: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited Message-ID: <B2FD678A64EAAD45B089B123FDFC3ED72B96D3495D@inbmail01.lsi.com> In-Reply-To: <20120223101157.0bb3f2ee@kan.dyndns.org> References: <B2FD678A64EAAD45B089B123FDFC3ED72B96D3484A@inbmail01.lsi.com> <20120223094611.GC32748@hoeg.nl> <B2FD678A64EAAD45B089B123FDFC3ED72B96D34929@inbmail01.lsi.com> <20120223101157.0bb3f2ee@kan.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----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" <Kashyap.Desai@lsi.com> 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 <Kashyap.Desai@lsi.com>, 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 <ed@80386.nl> > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B2FD678A64EAAD45B089B123FDFC3ED72B96D3495D>