mpslsi0 : Trying sleep, but thread marked as sleeping prohibited

[Bruce Evans]

On Fri, 24 Feb 2012, Desai, Kashyap wrote:

>> From: Alexander Kabaev [mailto:kabaev at gmail.com]
>> ...
>> 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 is bit lengthy work) under that.
> It looks mps driver is miss using mtx_lock. Are we ?

No.  Most NIC drivers do this.

Lengthy work isn't as long as it used to be, and here the lock only locks
out other accesses to a single piece of hardware (provided sc is for a
single piece of hardware as it should be).  Worry instead about more
global locks, either in your driver or in upper layers.  You might need
one to lock your whole driver, and upper layers might need one to lock
things globally too.  Giant locking is an example of the latter.  I don't
trust the upper layers much, but for interrupt handling they can be trusted
to not have anything locked when the interrupt handler is called (except
for Giant locking when the driver requests this).  Also worry about your
interrupt handler taking too long -- although nothing except interrupt
thread priority prevents other code running, it is possible that other
code doesn't get enough (or any) cycles if an interrupt handler is too
hoggish.  This problem is smaller than when there was a single ~1 MHz
CPU doing PIO.  With multiple ~2GHz CPUs doing DMA, the interrupt handler
can often be 100 times sloppier without anyone noticing.  But not 1000
times, and not 100 times with certain hardware.

Bruce