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
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."
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
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
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
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
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