James Bottomley wrote:
On Sat, 2009-03-14 at 16:48 -0600, Matthew Wilcox wrote:
On Sat, Mar 14, 2009 at 03:41:31PM -0500, James Bottomley wrote:
We're going to have to do something about the scary error messages on
SBC-2 supporting drives, this is what mine say (and this is after mkp's
chat reduction):
sd 1:0:1:0: [sdc] READ CAPACITY(16) failed
sd 1:0:1:0: [sdc] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sd 1:0:1:0: [sdc] Sense Key : Illegal Request [current]
sd 1:0:1:0: [sdc] Add. Sense: Invalid command operation code
sd 1:0:1:0: [sdc] 71096640 512-byte hardware sectors: (36.4 GB/33.9 GiB)
OK, that's relatively easy to fix. Simply return early if the drive
claims not to understand the command, and it'll try rc10 without printing
the scary messages. Like this, perhaps (note cunning factoring of code):
(compile tested only, and I'll do you a nice changelog and sign-off for
it if it fixes the problem and you approve of this approach).
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index f8260c0..60b31ea 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -1139,6 +1139,14 @@ static int media_not_present(struct scsi_disk *sdkp,
return 1;
}
+static int invalid_field_in_cdb(struct scsi_sense_hdr *sshdr)
+{
+ if (!scsi_sense_valid(sshdr))
+ return 0;
+ return sshdr->sense_key == ILLEGAL_REQUEST &&
+ sshdr->asc == 0x24 && sshdr->ascq == 0x0;
+
Actually, afraid not, you're trapped in the confusing maze of ASC/ASCQ
codes, all sounding alike but meaning slightly different things:
0x24/0x00 is Invalid Field in CDB. The problem I'm having is 0x20/00
(Invalid Command Operation Code).
This will fix it, though ... I'll just merge it into your patch.
Read Capacity(16) is actually Service Action In(16) with a
Service Action field of 10h. My understanding is that if the
device server doesn't support Service Action(16) (i.e. the
"operation code" is the first byte of the cdb) then 20h/0h is
the ASC/ASCQ response. However it if does support Service
Action In(16) but not a Read Capacity(16) then 24h/0h is the
correct ASC/ASCQ response.
The only example I can see of the latter case is if Read
Long(16) is supported and Read Capacity(16) isn't. Then
opcode 9eh (Service Action In(16)) is valid.
I suspect that the folks who implement SCSI disk
firmware are also confused. I'm pretty sure that I have
seen these two ASC/ASCQ combinations used interchangeably
for unsupported commands that have a service action field.
Doug Gilbert
--
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
