On Tue, May 22, 2001 at 12:21:58PM -0700, Matthew Jacob wrote:
> 
> > 
> > This is why I propose to make scsipi_channel_thaw public, this once can be
> > called from your thread. But I don't think we should allow HBA drivers to
> > bypass the freeze/thaw mechanism; this will break if we want to change the
> > internals of scsipi.
> > 
> 
> Can we come to some closure on this? I have a fairly large change to the FC
> driver (which now quite nicely survives and retries LIPS after loop
> re-evaluation where it didn't before) that I'd like to check in.
> 
> The current usage of scsipi_channel_thaw (which is public) does not call
> scsipi_run_queue. The reason why this is not currently broken is that the
> current usage of freeze/thaw is for resource shortage reasons, and some HBA
> driver (ahc, e.g.) call scsipi_channel_thaw prior to calling scsipi_done
> (which will call scspi_run_queue).
> 
> However, I'm talking about events which can unfreeze a queue with no commands
> active. Therefore, I either have to call scspi_run_queue directly, or I have
> to have some variant of scsipi_channel_thaw which makes sure that the queue
> gets started again.
> 
> Suggestions?

I think I can make scsipi_channel_thaw() run the queue if the count drops to 0.
This may require changes to other drivers using scsipi_channel_thaw() to make
sure it's safe to queue commands again when scsipi_channel_thaw() is used,
but this should be easy.

I'll try to look at this tomorow.

--
Manuel Bouyer <bouyer@antioche.eu.org>
--