* READ CAPACITY (16) failing
@ 2009-04-08 19:43 Mike Miller (OS Dev)
2009-04-08 19:54 ` Matthew Wilcox
0 siblings, 1 reply; 7+ messages in thread
From: Mike Miller (OS Dev) @ 2009-04-08 19:43 UTC (permalink / raw)
To: LKML-SCSI, LKML; +Cc: mike.miller
Hello,
I'm working on the HP Smart Array SCSI driver (hpsa) and I'm seeing the
following failures:
hpsa1: <0x3230> at PCI 0000:02:00.0 IRQ 76 using DAC
scsi4 : hpsa
scsi 4:0:0:0: Direct-Access HP LOGICAL VOLUME 5.20 PQ: 0 ANSI: 5
sd 4:0:0:0: Attached scsi generic sg4 type 0
sd 4:0:0:0: [sdd] READ CAPACITY(16) failed
sd 4:0:0:0: [sdd] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
sd 4:0:0:0: [sdd] Sense not available.
hpsa: cp ffff8800cf400000 has check condition: unknown type: Sense: 0x5,
ASC: 0x20, ASCQ: 0x0, Returning result: 0x2, cmd=[a0 00 00 00 00 00 00 00 10
00]
sd 4:0:0:0: [sdd] 213196320 512-byte hardware sectors: (109 GB/101 GiB)
sd 4:0:0:0: [sdd] Write Protect is off
sd 4:0:0:0: [sdd] Mode Sense: 6b 00 00 08
sd 4:0:0:0: [sdd] Write cache: disabled, read cache: enabled, doesn't
support DPO or FUA
sd 4:0:0:0: [sdd] READ CAPACITY(16) failed
sd 4:0:0:0: [sdd] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
sd 4:0:0:0: [sdd] Sense not available.
sdd: sdd1
sd 4:0:0:0: [sdd] Attached SCSI disk
scsi 4:1:0:0: RAID HP P400 5.20 PQ: 0 ANSI: 0
scsi 4:1:0:0: Attached scsi generic sg5 type 12
The illegal request is coming from smartd and probably doesn't mean anything
in this context since SA doesn't support the SCSI Report LUNs command. The
READ CAPACITY failures are what I'm concerned about. I can't seem to track
down why that's failing.
I've tried printing out the_result from sd but it's not printing out. I'm
assuming that anytime I load the driver it goes thru sd.
if (the_result) {
sense_valid = scsi_sense_valid(&sshdr);
if (sense_valid &&
sshdr.sense_key == ILLEGAL_REQUEST &&
(sshdr.asc == 0x20 || sshdr.asc == 0x24) &&
sshdr.ascq == 0x00)
/* Invalid Command Operation Code or
* Invalid Field in CDB, just retry
* silently with RC10 */
return -EINVAL;
}
retries--;
} while (the_result && retries);
printk(KERN_WARNING "sd-mfm: the_result = %d\n", the_result);
sd reports:
sd 4:0:0:0: [sdd] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
>From the controllers serial port I see:
[04/08 14:31:09]Ctlr SCSI Request, Illegal CDB Opcode=0x0
[04/08 14:37:28]Volume SCSI Request, Illegal CDB Opcode=0xa0
when the driver loads. I guess the TUR is coming from sd. But neither of
these indicate why the READ CAPACITY (16) failed.
I've also tried printing out the command status from the driver but it only
shows a check condition with no sense.
Any ideas? Or is there not enough info here?
Thanks,
mikem
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: READ CAPACITY (16) failing 2009-04-08 19:43 READ CAPACITY (16) failing Mike Miller (OS Dev) @ 2009-04-08 19:54 ` Matthew Wilcox 2009-04-09 15:22 ` Mike Miller (OS Dev) 2009-04-10 19:31 ` Mike Miller (OS Dev) 0 siblings, 2 replies; 7+ messages in thread From: Matthew Wilcox @ 2009-04-08 19:54 UTC (permalink / raw) To: Mike Miller (OS Dev); +Cc: LKML-SCSI, LKML, mike.miller On Wed, Apr 08, 2009 at 02:43:57PM -0500, Mike Miller (OS Dev) wrote: > I'm working on the HP Smart Array SCSI driver (hpsa) and I'm seeing the > following failures: > > hpsa1: <0x3230> at PCI 0000:02:00.0 IRQ 76 using DAC > scsi4 : hpsa > scsi 4:0:0:0: Direct-Access HP LOGICAL VOLUME 5.20 PQ: 0 ANSI: 5 > sd 4:0:0:0: Attached scsi generic sg4 type 0 > sd 4:0:0:0: [sdd] READ CAPACITY(16) failed > sd 4:0:0:0: [sdd] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK > sd 4:0:0:0: [sdd] Sense not available. > hpsa: cp ffff8800cf400000 has check condition: unknown type: Sense: 0x5, > ASC: 0x20, ASCQ: 0x0, Returning result: 0x2, cmd=[a0 00 00 00 00 00 00 00 10 > 00] > The READ CAPACITY failures are what I'm concerned about. I can't seem to track > down why that's failing. > I've tried printing out the_result from sd but it's not printing out. I'm > assuming that anytime I load the driver it goes thru sd. > > if (the_result) { > sense_valid = scsi_sense_valid(&sshdr); > if (sense_valid && > sshdr.sense_key == ILLEGAL_REQUEST && > (sshdr.asc == 0x20 || sshdr.asc == 0x24) && > sshdr.ascq == 0x00) > /* Invalid Command Operation Code or > * Invalid Field in CDB, just retry > * silently with RC10 */ > return -EINVAL; > } > retries--; > } while (the_result && retries); > printk(KERN_WARNING "sd-mfm: the_result = %d\n", the_result); Probably the device you're testing against doesn't support RC16, which is fine. But for some reason, we're not getting valid sense data back from the device. Now, there's two responses to this that seem rational to me: - In sd.c, if the drive has returned no/invalid sense data, try RC10 silently, just like the 0x20 / 0x24 ASC case. - Find out why this drive doesn't report valid sense data when attached to hpsa. I assume it does report valid sense data when attached to some other scsi card? -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: READ CAPACITY (16) failing 2009-04-08 19:54 ` Matthew Wilcox @ 2009-04-09 15:22 ` Mike Miller (OS Dev) 2009-04-10 19:31 ` Mike Miller (OS Dev) 1 sibling, 0 replies; 7+ messages in thread From: Mike Miller (OS Dev) @ 2009-04-09 15:22 UTC (permalink / raw) To: Matthew Wilcox; +Cc: LKML-SCSI, LKML, mike.miller On Wed, Apr 08, 2009 at 01:54:48PM -0600, Matthew Wilcox wrote: > On Wed, Apr 08, 2009 at 02:43:57PM -0500, Mike Miller (OS Dev) wrote: > > I'm working on the HP Smart Array SCSI driver (hpsa) and I'm seeing the > > following failures: > > > > hpsa1: <0x3230> at PCI 0000:02:00.0 IRQ 76 using DAC > > scsi4 : hpsa > > scsi 4:0:0:0: Direct-Access HP LOGICAL VOLUME 5.20 PQ: 0 ANSI: 5 > > sd 4:0:0:0: Attached scsi generic sg4 type 0 > > sd 4:0:0:0: [sdd] READ CAPACITY(16) failed > > sd 4:0:0:0: [sdd] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK > > sd 4:0:0:0: [sdd] Sense not available. > > hpsa: cp ffff8800cf400000 has check condition: unknown type: Sense: 0x5, > > ASC: 0x20, ASCQ: 0x0, Returning result: 0x2, cmd=[a0 00 00 00 00 00 00 00 10 > > 00] > > > The READ CAPACITY failures are what I'm concerned about. I can't seem to track > > down why that's failing. > > I've tried printing out the_result from sd but it's not printing out. I'm > > assuming that anytime I load the driver it goes thru sd. > > > > if (the_result) { > > sense_valid = scsi_sense_valid(&sshdr); > > if (sense_valid && > > sshdr.sense_key == ILLEGAL_REQUEST && > > (sshdr.asc == 0x20 || sshdr.asc == 0x24) && > > sshdr.ascq == 0x00) > > /* Invalid Command Operation Code or > > * Invalid Field in CDB, just retry > > * silently with RC10 */ > > return -EINVAL; > > } > > retries--; > > } while (the_result && retries); > > printk(KERN_WARNING "sd-mfm: the_result = %d\n", the_result); > > Probably the device you're testing against doesn't support RC16, which > is fine. But for some reason, we're not getting valid sense data back > from the device. Now, there's two responses to this that seem rational > to me: > > - In sd.c, if the drive has returned no/invalid sense data, try RC10 > silently, just like the 0x20 / 0x24 ASC case. > - Find out why this drive doesn't report valid sense data when attached > to hpsa. I assume it does report valid sense data when attached to > some other scsi card? If I connect to another card everything seems to work OK. But, the controllers I'm testing with DO support RC16. If I load the cciss driver I can see my large volumes with no problems. I've also bugged the firmware folks and according to them RC16 is supported. WRT the TUR failing, if this controller message is accurate it looks like the TUR is being sent to the controller and not the logical volumes. [04/08 14:31:09]Ctlr SCSI Request, Illegal CDB Opcode=0x0 Wonder why that would be the case. -- mikem ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: READ CAPACITY (16) failing 2009-04-08 19:54 ` Matthew Wilcox 2009-04-09 15:22 ` Mike Miller (OS Dev) @ 2009-04-10 19:31 ` Mike Miller (OS Dev) 2009-04-10 21:04 ` Douglas Gilbert 2009-04-10 22:28 ` James Bottomley 1 sibling, 2 replies; 7+ messages in thread From: Mike Miller (OS Dev) @ 2009-04-10 19:31 UTC (permalink / raw) To: Matthew Wilcox; +Cc: LKML-SCSI, LKML, mike.miller, James Bottomley On Wed, Apr 08, 2009 at 01:54:48PM -0600, Matthew Wilcox wrote: > On Wed, Apr 08, 2009 at 02:43:57PM -0500, Mike Miller (OS Dev) wrote: > > I'm working on the HP Smart Array SCSI driver (hpsa) and I'm seeing the > > following failures: > > > > hpsa1: <0x3230> at PCI 0000:02:00.0 IRQ 76 using DAC > > scsi4 : hpsa > > scsi 4:0:0:0: Direct-Access HP LOGICAL VOLUME 5.20 PQ: 0 ANSI: 5 > > sd 4:0:0:0: Attached scsi generic sg4 type 0 > > sd 4:0:0:0: [sdd] READ CAPACITY(16) failed > > sd 4:0:0:0: [sdd] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK > > sd 4:0:0:0: [sdd] Sense not available. > > hpsa: cp ffff8800cf400000 has check condition: unknown type: Sense: 0x5, > > ASC: 0x20, ASCQ: 0x0, Returning result: 0x2, cmd=[a0 00 00 00 00 00 00 00 10 > > 00] > > > The READ CAPACITY failures are what I'm concerned about. I can't seem to track > > down why that's failing. > > I've tried printing out the_result from sd but it's not printing out. I'm > > assuming that anytime I load the driver it goes thru sd. > > > > if (the_result) { > > sense_valid = scsi_sense_valid(&sshdr); > > if (sense_valid && > > sshdr.sense_key == ILLEGAL_REQUEST && > > (sshdr.asc == 0x20 || sshdr.asc == 0x24) && > > sshdr.ascq == 0x00) > > /* Invalid Command Operation Code or > > * Invalid Field in CDB, just retry > > * silently with RC10 */ > > return -EINVAL; > > } > > retries--; > > } while (the_result && retries); > > printk(KERN_WARNING "sd-mfm: the_result = %d\n", the_result); > > Probably the device you're testing against doesn't support RC16, which > is fine. But for some reason, we're not getting valid sense data back > from the device. Now, there's two responses to this that seem rational > to me: > > - In sd.c, if the drive has returned no/invalid sense data, try RC10 > silently, just like the 0x20 / 0x24 ASC case. > - Find out why this drive doesn't report valid sense data when attached > to hpsa. I assume it does report valid sense data when attached to > some other scsi card? Me again, The controllers do support RC16. After some more work it looks like RC16 is never getting to the driver. I'm snooping the CDB's of all requests as well as the completions from the driver and I never see a 0x9e. I do see the RC10 (0x25) though, so I think my debug is right. Why would I never the see the command in the driver? -- mikem ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: READ CAPACITY (16) failing 2009-04-10 19:31 ` Mike Miller (OS Dev) @ 2009-04-10 21:04 ` Douglas Gilbert 2009-04-10 22:28 ` James Bottomley 1 sibling, 0 replies; 7+ messages in thread From: Douglas Gilbert @ 2009-04-10 21:04 UTC (permalink / raw) To: Mike Miller (OS Dev) Cc: Matthew Wilcox, LKML-SCSI, LKML, mike.miller, James Bottomley Mike Miller (OS Dev) wrote: > On Wed, Apr 08, 2009 at 01:54:48PM -0600, Matthew Wilcox wrote: >> On Wed, Apr 08, 2009 at 02:43:57PM -0500, Mike Miller (OS Dev) wrote: >>> I'm working on the HP Smart Array SCSI driver (hpsa) and I'm seeing the >>> following failures: >>> >>> hpsa1: <0x3230> at PCI 0000:02:00.0 IRQ 76 using DAC >>> scsi4 : hpsa >>> scsi 4:0:0:0: Direct-Access HP LOGICAL VOLUME 5.20 PQ: 0 ANSI: 5 >>> sd 4:0:0:0: Attached scsi generic sg4 type 0 >>> sd 4:0:0:0: [sdd] READ CAPACITY(16) failed >>> sd 4:0:0:0: [sdd] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK >>> sd 4:0:0:0: [sdd] Sense not available. >>> hpsa: cp ffff8800cf400000 has check condition: unknown type: Sense: 0x5, >>> ASC: 0x20, ASCQ: 0x0, Returning result: 0x2, cmd=[a0 00 00 00 00 00 00 00 10 >>> 00] >>> The READ CAPACITY failures are what I'm concerned about. I can't seem to track >>> down why that's failing. >>> I've tried printing out the_result from sd but it's not printing out. I'm >>> assuming that anytime I load the driver it goes thru sd. >>> >>> if (the_result) { >>> sense_valid = scsi_sense_valid(&sshdr); >>> if (sense_valid && >>> sshdr.sense_key == ILLEGAL_REQUEST && >>> (sshdr.asc == 0x20 || sshdr.asc == 0x24) && >>> sshdr.ascq == 0x00) >>> /* Invalid Command Operation Code or >>> * Invalid Field in CDB, just retry >>> * silently with RC10 */ >>> return -EINVAL; >>> } >>> retries--; >>> } while (the_result && retries); >>> printk(KERN_WARNING "sd-mfm: the_result = %d\n", the_result); >> Probably the device you're testing against doesn't support RC16, which >> is fine. But for some reason, we're not getting valid sense data back >> from the device. Now, there's two responses to this that seem rational >> to me: >> >> - In sd.c, if the drive has returned no/invalid sense data, try RC10 >> silently, just like the 0x20 / 0x24 ASC case. >> - Find out why this drive doesn't report valid sense data when attached >> to hpsa. I assume it does report valid sense data when attached to >> some other scsi card? > > Me again, > The controllers do support RC16. After some more work it looks like RC16 is > never getting to the driver. I'm snooping the CDB's of all requests as well > as the completions from the driver and I never see a 0x9e. I do see the > RC10 (0x25) though, so I think my debug is right. > > Why would I never the see the command in the driver? struct Scsi_host::max_cmd_len < 16 would be one reason but one would expect an indicative message in the log. Does a 'sg_readcap --long -vvv <device>' give you any further information? Doug Gilbert ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: READ CAPACITY (16) failing 2009-04-10 19:31 ` Mike Miller (OS Dev) 2009-04-10 21:04 ` Douglas Gilbert @ 2009-04-10 22:28 ` James Bottomley 2009-04-14 18:23 ` Mike Miller (OS Dev) 1 sibling, 1 reply; 7+ messages in thread From: James Bottomley @ 2009-04-10 22:28 UTC (permalink / raw) To: Mike Miller (OS Dev); +Cc: Matthew Wilcox, LKML-SCSI, LKML, mike.miller On Fri, 2009-04-10 at 14:31 -0500, Mike Miller (OS Dev) wrote: > On Wed, Apr 08, 2009 at 01:54:48PM -0600, Matthew Wilcox wrote: > > On Wed, Apr 08, 2009 at 02:43:57PM -0500, Mike Miller (OS Dev) wrote: > > > I'm working on the HP Smart Array SCSI driver (hpsa) and I'm seeing the > > > following failures: > > > > > > hpsa1: <0x3230> at PCI 0000:02:00.0 IRQ 76 using DAC > > > scsi4 : hpsa > > > scsi 4:0:0:0: Direct-Access HP LOGICAL VOLUME 5.20 PQ: 0 ANSI: 5 > > > sd 4:0:0:0: Attached scsi generic sg4 type 0 > > > sd 4:0:0:0: [sdd] READ CAPACITY(16) failed > > > sd 4:0:0:0: [sdd] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK > > > sd 4:0:0:0: [sdd] Sense not available. > > > hpsa: cp ffff8800cf400000 has check condition: unknown type: Sense: 0x5, > > > ASC: 0x20, ASCQ: 0x0, Returning result: 0x2, cmd=[a0 00 00 00 00 00 00 00 10 > > > 00] > > > > > The READ CAPACITY failures are what I'm concerned about. I can't seem to track > > > down why that's failing. > > > I've tried printing out the_result from sd but it's not printing out. I'm > > > assuming that anytime I load the driver it goes thru sd. > > > > > > if (the_result) { > > > sense_valid = scsi_sense_valid(&sshdr); > > > if (sense_valid && > > > sshdr.sense_key == ILLEGAL_REQUEST && > > > (sshdr.asc == 0x20 || sshdr.asc == 0x24) && > > > sshdr.ascq == 0x00) > > > /* Invalid Command Operation Code or > > > * Invalid Field in CDB, just retry > > > * silently with RC10 */ > > > return -EINVAL; > > > } > > > retries--; > > > } while (the_result && retries); > > > printk(KERN_WARNING "sd-mfm: the_result = %d\n", the_result); > > > > Probably the device you're testing against doesn't support RC16, which > > is fine. But for some reason, we're not getting valid sense data back > > from the device. Now, there's two responses to this that seem rational > > to me: > > > > - In sd.c, if the drive has returned no/invalid sense data, try RC10 > > silently, just like the 0x20 / 0x24 ASC case. > > - Find out why this drive doesn't report valid sense data when attached > > to hpsa. I assume it does report valid sense data when attached to > > some other scsi card? > > Me again, > The controllers do support RC16. After some more work it looks like RC16 is > never getting to the driver. I'm snooping the CDB's of all requests as well > as the completions from the driver and I never see a 0x9e. I do see the > RC10 (0x25) though, so I think my debug is right. > > Why would I never the see the command in the driver? Because your devices are reporting compliance to a standard before RC16 was implemented (we have a check in sd_try_rc16_first() to see if you comply to higher than SBC-2). Then, after you've failed this, if you don't return the conventional 0xffffffff to RC10, we never retry with RC16. James ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: READ CAPACITY (16) failing 2009-04-10 22:28 ` James Bottomley @ 2009-04-14 18:23 ` Mike Miller (OS Dev) 0 siblings, 0 replies; 7+ messages in thread From: Mike Miller (OS Dev) @ 2009-04-14 18:23 UTC (permalink / raw) To: James Bottomley; +Cc: Matthew Wilcox, LKML-SCSI, LKML, mike.miller On Fri, Apr 10, 2009 at 03:28:38PM -0700, James Bottomley wrote: > > > > Why would I never the see the command in the driver? > > Because your devices are reporting compliance to a standard before RC16 > was implemented (we have a check in sd_try_rc16_first() to see if you > comply to higher than SBC-2). Then, after you've failed this, if you > don't return the conventional 0xffffffff to RC10, we never retry with > RC16. Thanks, James, that looks like the culprit. The LUN actually reports that it is a SCSI_SPC_3 device but the controller reports SCSI_UNKNOWN. I'll work with the firmware guys to fix that. Oddly enough, others here don't report seeing the same RC16 failure. Gets better and better. Thanks, mikem ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-04-14 18:23 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-04-08 19:43 READ CAPACITY (16) failing Mike Miller (OS Dev) 2009-04-08 19:54 ` Matthew Wilcox 2009-04-09 15:22 ` Mike Miller (OS Dev) 2009-04-10 19:31 ` Mike Miller (OS Dev) 2009-04-10 21:04 ` Douglas Gilbert 2009-04-10 22:28 ` James Bottomley 2009-04-14 18:23 ` Mike Miller (OS Dev)
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox