On Tue, 2010-05-04 at 15:27 -0500, Mike Christie wrote:
quoted text
> On 05/04/2010 03:15 PM, Mike Christie wrote:
> > On 05/04/2010 11:26 AM, James Bottomley wrote:
> >> The other patch is fine, but I don't think this is necessary. The
> >> reason is that even returning SUCCESS here, we go straight into
> >> scsi_finish_command() (which passes it up to the driver handler) and
> >> then scsi_io_completion(). There's a catch for UNIT_ATTENTION in
> >> scsi_io_completion
> >
> > The request is sent as a REQ_TYPE_BLOCK_PC (this flag is set for the
> > request in sd_prepare_flush), and scsi_io_completion's blk_pc_request
> > check() that returns the request upwards is before the UNIT_ATTENTION
> 
> I was looking at the wrong source.
> 
> scsi_finish_command checks for REQ_TYPE_BLOCK_PC and sets good_bytes to 
> scsi_bufflen, so when scsi_io_completion calls scsi_end_request, it 
> fails the request before we can get to the UNIT_ATTENTION.

Ah, yes, missed that.

However there are other problems then.  We can't just eat all unit
attentions on the BLOCK_PC path because some of the user programs want
to see them (CD burners for one).  I know the patch allows some to
proceed upwards, but it's risky making all except device not started do
a retry.

I'm a bit stumped on this one ... the intention of BLOCK_PC is that the
caller simply retries if they get a unit attention (which is what all
SCSI code does).  The block code doesn't want to look at the sense data
but at the error return.  I suppose we could make UNIT_ATTENTION
translate to -EAGAIN and have block do the right thing?

James


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html