This is mostly needed because an AztecMonster II target has been
observed disconnecting REQUEST SENSE commands and then failing
to reselect properly.
Suggested-by: Michael Schmitz
Tested-by: Michael Schmitz
Signed-off-by: Finn Thain
---
drivers/scsi/NCR5380.c | 4 +++-
1 file changed, 3
.org
> Subject: Re: scsi error handling thread and REQUEST SENSE
>
>
> On Mon, 2014-05-19 at 10:32 +0200, Hannes Reinecke wrote:
> > On 05/16/2014 10:05 PM, Ewan Milne wrote:
> > > On Fri, 2014-05-16 at 19:02 +, Elliott, Robert (Server Storage)
> > > wrote:
&g
SCSI_SENSE_VALID(scmd))
> >> continue;
> >>
> >> In this case, that if statement fails. The eflags bit is not
> >> set, and the sense data buffer still contains zeros or garbage -
> >> the command is still outstandi
On 05/16/14 21:02, Elliott, Robert (Server Storage) wrote:
> The command is still outstanding; data transfers might still occur,
> and a completion using its tag could still appear at any time.
> However, the error handler declares that the command is done,
> so all the buffers are freed and the
On 05/19/14 12:37, Hannes Reinecke wrote:
> Plus this is just a test patch, nothing official yet.
> I'm happy to include the changes for SRP if you can confirm that SRP
> requires autosense.
Hello Hannes,
Since the SRP protocol supports returning sense data in the SRP response
message and since e
On 05/19/2014 12:29 PM, Bart Van Assche wrote:
On 05/19/14 10:32, Hannes Reinecke wrote:
Well, problem here is that the 'REQUEST SENSE' command has two problems:
a) Most modern HBA (ie all non-SPI HBAs) use autosense, ie the sense
code is returned with the command. So issuing
On 05/19/14 10:32, Hannes Reinecke wrote:
> Well, problem here is that the 'REQUEST SENSE' command has two problems:
> a) Most modern HBA (ie all non-SPI HBAs) use autosense, ie the sense
> code is returned with the command. So issuing 'REQUEST SENSE' here is
> poin
n, and this lacks support for descriptor format
sense data (type 0x72), but those are side issues)
Doesn't the check for: (byte[0] & 0x70) == 0x70 cover 0x70 - 0x73?
Strangely, the error handler code (scsi_unjam_host()) proceeds
to send a REQUEST SENSE command and sees the resulting
s still outstanding, so the buffer might be written
> at any time.
>
> (the sense buffer shouldn't be read unless a valid bit says
> it's filled in, and this lacks support for descriptor format
> sense data (type 0x72), but those are side issues)
Doesn't the check
d this lacks support for descriptor format
sense data (type 0x72), but those are side issues)
Strangely, the error handler code (scsi_unjam_host()) proceeds
to send a REQUEST SENSE command and sees the resulting sense
key of NO SENSE:
[ 5454.381659] sd 2:0:0:1: [sds] scsi_eh_2: reques
On 03/28/2014 06:50 PM, James Bottomley wrote:
> We unconditionally execute scsi_eh_get_sense() to make sure all failed
> commands that should have sense attached, do. However, the routine forgets
> that some commands, because of the way they fail, will not have any sense code
> ... we should not
if (status_byte(scmd->result) != CHECK_CONDITION)
+ /*
+* don't request sense if there's no check condition
+* status because the error we're processing isn't one
+* that has a sens
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/17/2013 1:02 PM, Sergei Shtylyov wrote:
> Isn't it an optional command, belonging to the power management
> feature set?
Seems to be required. ATA-8 section 4.16 says:
"A General feature set device shall implement power management"
-BEG
Hello.
On 12/17/2013 02:30 AM, Phillip Susi wrote:
SAT-3 says REQUEST SENSE should issue CHECK POWER and return
a sense status indicating the drive's power status.
---
drivers/ata/libata-scsi.c | 40 ++--
1 file changed, 34 insertions(+), 6 dele
SAT-3 says REQUEST SENSE should issue CHECK POWER and return
a sense status indicating the drive's power status.
---
drivers/ata/libata-scsi.c | 40 ++--
1 file changed, 34 insertions(+), 6 deletions(-)
diff --git a/drivers/ata/libata-scsi.c b/driver
This patch fixes a problem discovered on a system with some
bad SATA devices attached. If a command to a SATAPI device
times out and the device gets reset as part of error recovery,
its possible that ipr will set err_mask to indicate a device
error has occurred. If this happens, a request sense
In the switch over, I forgot to set the command length, so it sends out
a request sense with whatever length the prior command had (and fails
badly if it wasn't 6).
James
diff --git a/drivers/scsi/53c700.c b/drivers/scsi/53c700.c
index 562432d..9aabb64 100644
--- a/drivers/scsi/53c700.c
On Fri, Feb 25, 2005 at 03:37:50PM +, Matthew Wilcox wrote:
> On Fri, Feb 25, 2005 at 02:02:20PM +1000, Douglas Gilbert wrote:
> > Back in SCSI-2 (final t10 draft in 1993, standard in 1994) all
> > SCSI commands (I believe) used the top 3 bits of byte 1 of a cdb
> > for the logical unit number
, IMO.
>
> The LLD obviously knows the version of SPI that a target
> supports and the "version" field in an INQUIRY response
> indicates which SCSI command set generation the device claims
> to support (SPC-3 rev 21d, table 81 on page 145). As has been
> discussed e
ion of SPI that a target
supports and the "version" field in an INQUIRY response
indicates which SCSI command set generation the device claims
to support (SPC-3 rev 21d, table 81 on page 145). As has been
discussed elsewhere, one should not necessary believe the
value a device puts in the
Found a funny in the sym2 driver I'm not sure how to resolve:
cp->sensecmd[0] = REQUEST_SENSE;
cp->sensecmd[1] = 0;
if (tp->tinfo.curr.scsi_version <= 2 && cp->lun <= 7)
cp->sensecmd[1] = cp->lun << 5;
Thing
21 matches
Mail list logo
