> 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.

Okay, thanks.

Insofar as keeping a count- this one can do, but it makes the added value
of this midlayer drop. It should be clear who can and who cannot modify the
channel freeze count, and when- otherwise I can guarantee you that there will
be cases where nobody will unfreeze when they should. I'd argue that the
channel freeze count should be read-only for the midlayer (except by being
tweaked via the freeze/thaw functions) and solely up to the HBA as to what
value it should be.

There are also different, independent, reasons to do a queue freeze.

For example, I have to keep track of which of the counts I myself have applied
for reasons of Loop state changes and which for resource exhaustion.

Why? Well, you send back commands to requeued with different answers based
upon which is currently active (XS_RESOURCE_SHORTAGE and XS_REQUEUE).

-matt