>>>>> On 15 May 1996 21:28:40 -0400,
	mycroft@mit.edu (Charles M. Hannum) said:

>> This fix seems to be easy to implement, and doesn't change traditional
>> behavior of xxstart(). (xxstart() can be called from interrupt)

> By itself, this isn't sufficient, because you wouldn't be guaranteed
> to notify the higher-level driver when a slot (SCB) becomes available.
> (Consider the case where other devices are currently hogging all the
> slots.  There won't be a call to scsi_done() for that device, so its
> start routine won't be called again unless someone queues another I/O
> operation.)

But we can implement queue which holds devices that it's xxstart()
should be called from scsi_done().... Hmm...
Sure, we can't call this easy workaround as I thought, because this
fix requires that adapter <-> MI SCSI interface is modified, since the
queue should be owned by adapter (not scsibus),

# using timeout to fix this seems to fall into starvation...

> Additionally, the behaviour suggested in item 2 would require either
> disallowing the start routine from ever sleeping (meaning that it
> would always have to use SCSI_NOSLEEP), or adding an additional lock
> to prevent another process entering the start routine (from the
> strategy routine) and trying to start the same buffer.

I thought doing both the former and the latter.

> Also, if you disallow sleeping in the strategy routine (which would be
> the only real point to completely disallowing it in the start
> routine), this still doesn't solve the problem of where you allocate
> resources.

I overlooked this too, because the few SCBs problem doesn't concern
with this (SCBs are already allocated by hardware), and had not
thought that you think that M_NOWAIT is also problem. (I thought it is
OK to allocate minimum number of resources in device attaching routine).

Thanks! anyway.
--
soda@sra.co.jp		Software Research Associates, Inc., Japan
(Noriyuki Soda)		   software tools and technology group