--- Mike Anderson <andmike@xxxxxxxxxx> wrote:
> James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
> > On Tue, 2006-08-22 at 13:53 -0700, Mike Anderson wrote:
> > > Does this help any? While Alexis and I where working on a expander timeout
> > > issue the abort was never working for us. I compared the adp abort and the
> > > aic94xx abort code and made these changes. This appears to make the abort
> > > work for us now. A few lines of the changes are not related to the abort.
> > > YMMV, a better solution would be to know the exact format of the abort.
> >
> > Actually, no. I still seem to get the same problem (at least it BUGs in
> > the same place ... I haven't dug down to see if I'm getting the same
> > return value).
>
> Well the adp driver had a comment that the 0x1D error code means that it
> cannot find the command in its execution queue as it already has sent the
> command to the target(if I mapped this right between the two drivers).
> What looks odd is in the adp driver that move to a higher level of
> recovery (i.e., lun reset) if they receive this code, but in the aic94xx
> we mark the task TMF_RESP_FUNC_COMPLETE which appears wrong as you found
> out with the BUG_ON.
There is much more to that. If you followed my previous email... SSP is
handled differently so you cannot just do LU Reset. Depening on other
factors, you may or you may not. If you always did then you're "error
recovery thrashing", and performance would suffer, so you might as well
use SATA...
Luben
>
> -andmike
> --
> Michael Anderson
> andmike@xxxxxxxxxx
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
