Re: [QUESTION]: Why did we clear the lowest bit of SCSI command's status in scsi_status_is_good

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Nov 28, 2022 at 11:24 PM James Bottomley <jejb@xxxxxxxxxxxxx> wrote:
>
> On Mon, 2022-11-28 at 22:41 +0800, Wenchao Hao wrote:
> > On 2022/11/28 20:52, James Bottomley wrote:
> > > On Mon, 2022-11-28 at 11:58 +0800, Wenchao Hao wrote:
> [...]
> > > > We found some firmware or drivers would return status which did
> > > > not defined in SAM. Now SCSI middle level do not have an uniform
> > > > behavior for these undefined status. I want to change the logic
> > > > to return error for all status which did not defined in SAM or
> > > > define a method in host template to let drivers to judge what to
> > > > do in this condition.
> > >
> > > Why? The general rule of thumb is be strict in what you emit and
> > > generous in what you receive (which is why reserved bits are
> > > ignored). Is the drive you refer to above not working in some way,
> > > in which case detail it so people can understand the actual
> > > problem.
> > >
> > > James
> > >
> > > .
> >
> >
> > We come with an issue with megaraid_sas driver. Where scsi_cmnd is
> > completed with result's status byte set to 1,
>
> Megaraid_sas is an emulation driver for the most part, so it sounds
> like this is in the RAID emulation firmware, correct?  The driver can
> correct for emulation failures, if you can figure out what it's trying
> to signal and convert it to the correct SAM error code. There's no need
> to change anything in the layers above.  If you can't figure out the
> translation and you want the transfer to error, then add DID_ERROR,
> which is a nice catch all.  If this is transient and could be fixed by
> a retry, then do DID_SOFT_ERROR instead.
>
> James
>

Thanks for your answer, Of curse we can recognize these undefined status
and map to an error which can be handled by SCSI middle level now. But I
still confused why shouldn't we change the scsi_status_is_good() to
respect to SAM?

I downloaded the sam6r08.pdf from t10.org, the status byte still did not
use the reserved bit. I think we should return an exact for all status
which is undefined in SAM rather than return true for some status
codes(0x1, 0x3, 0x5... and so on), but return false for other status.
I don't think there is any  difference between these undefined status.



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux