Re: [PATCH 5/24][RFC] dpt_i2o: Use new scsi_eh_cpy_sense()

[Boaz Harrosh <bharrosh@panasas.com>]

On Mon, Feb 04 2008 at 20:32 +0200, "Salyzyn, Mark" <Mark_Salyzyn@adaptec.com> wrote:
> ACK with condition that community accepts the RFC's entire premise.
> 
> The removed code that shunted the REQUEST_SENSE was based on the assumption 
> that the sense data in the current scsi command packet was left over from the 
> previous command's execution with a check condition as the scsi command packet 
> is reused to issue the REQUEST_SENSE. For a new, or second from the target's point 
> of view, request sense to the target issued by these older kernels would always 
> return an erased sense. The dpt_i2o driver does not itself maintain the sense history, 
> nor does the Firmware. This behavior, I believe, is not the case for current kernels so 
> the code fragment made little sense (pun not intended). If my historical knowledge is 
> correct, this (now removed) workaround makes no more sense because the scsi layer correctly 
> manages adapters that produce auto-request sense and does not ever turn around the command 
> and send a second request for sense information.

> Given this understanding, I have no problem with the removed fragment of REQUEST_SENSE shunting. 
> However, I do urge some target error recovery testing, tape drives being the likely type of target 
> affected by this change. I have no such hardware to confirm...
> Sincerely -- Mark Salyzyn

I have removed this test because the midlayer does a scsi_eh_reset_sense() just before
the new invocation of a command. So even if the second bad REQUEST_SENSE comes this
will not filter it out anymore. If such a thing still happens? A driver state machine
must be used to filter it out, or of course midlayer should be fixed.

Boaz