This message is from the T13 list server.
Rob
The "indeterminate results" was inserted after MS complained about
conflicting behaviors in drives. The issue being addressed is that there is
no place in any ATA standard that suggests to the host it should check
IDENTIFY DEVICE data to see if something is supported. The may have
indeterminate results was inserted to indicate to host software writers that
if they don't check IDENTIFY DEVICE data they could have problems. There
may be conditions that prevent the drive from aborting the command. There
are two things that are being addressed:
1. You were not violating the spec if you included a feature but did not
indicate support in identify device
2. Somebody distributed product that had an incorrect HW implementation on
one of they commands. They attempted to turn the feature off by removing
the indication from IDENTIFY DEVICE data.
The new wording sends a strong message to host software vendors that shot
gunning commands to the drive can result in hangs. This also places a
burden on device manufacturers to make the IDENTIFY DEVICE data be correct.
I believe that the new wording is not inconsistent, I believe that it is
correct and should stay...
-------------------------------------------------
Curtis E. Stevens
20511 Lake Forest Drive #C-214D
Lake Forest, California 92630
Phone: 949-672-7933
Cell: 949-307-5050
E-Mail: [EMAIL PROTECTED]
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Elliott,
Robert (Server Storage)
Sent: Friday, April 07, 2006 11:12 AM
To: [email protected]
Subject: RE: [t13] ATA8-ACS NOP proposals
This message is from the T13 list server.
One thing Mark has identified is that the response to a supported NOP
command does slightly differ from the response to an unsupported command,
even for Subcommand 00h.
NOP has fully defined output Error and Status values:
Error
15:8 reserved (set to 00h)
7:3 N/A (don't care)
2 ABRT set to 1
1:0 obsolete (don't care)
Status
15:8 reserved (set to 00h)
7:6 transport-dependent (usually BSY:DRDY; according to ATA/ATAPI-7, set
to 01b)
5 DF (report where the device has a fault or not)
4 N/A (don't care)
3 transport-dependent (usually DRQ; according to ATA/ATAPI-7, set to
zero)
2:1 N/A (don't care)
0 ERR set to 1 (because one of the bits in Error must be set to 1)
Commands that are not supported are not as well defined. ata8-acs-r3b has
two conflicting statements:
"6.2.1 Abort (ABRT)
Abort shall be set to one if the command is not supported.
7.17.2 IDENTIFY DEVICE
If the host issues a command that is indicated as not supported, the drive
may produce indeterminate results."
The "indeterminate" wording was only introduced into ATA8-ACS by e05131r1.
Perhaps it is too broad?
Indeterminate ABRT, ERR, BSY, DRDY, and DRQ might cause problems.
Indeterminate DF should be fine.
If 7.17.2 overrides 6.2.1, then ABRT is also indeterminate and 6.2.1 ought
to be a "should."
If 6.2.1 overrides 7.17.2, then 7.12.2 needs to say "indeterminate results
except for ABRT and ERR."
--
Rob Elliott, [EMAIL PROTECTED]
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott
> -----Original Message-----
> From: Curtis Stevens [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 07, 2006 11:00 AM
> To: Evans, Mark; Elliott, Robert (Server Storage); [email protected]
> Subject: RE: [t13] ATA8-ACS NOP proposals
>
> Mark
>
> That was all back in the early to mid 90s. Do you
> believe that it
> is relevant for systems today?
>
>
>
> -------------------------------------------------
> Curtis E. Stevens
> 20511 Lake Forest Drive #C-214D
> Lake Forest, California 92630
> Phone: 949-672-7933
> Cell: 949-307-5050
> E-Mail: [EMAIL PROTECTED]
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Evans,
> Mark
> Sent: Thursday, April 06, 2006 7:20 AM
> To: Elliott, Robert (Server Storage); [email protected]
> Subject: RE: [t13] ATA8-ACS NOP proposals
>
> This message is from the T13 list server.
>
>
> Hi Rob,
>
> I was reviewing your proposal (e06126r0) and have a serious
> issue (I won't
> go into the editorial issues I have with the proposal here). In the
> overview of your proposal you write, "However, since NOP with
> subcommand 00h
> returns the same result as an unsupported opcode, it doesn't
> matter if it is
> 'supported' or not." This isn't all NOP does. It DOES
> matter whether a
> device reports that the command is supported or not. You
> have to go back to
> what NOP was originally intended to do. The last place this
> is hinted at is
> in the description of NOP in ATA/ATAPI-4 rev 16, "This
> command enables a
> host, that only performs 16-bit register accesses, to check
> device status."
> It seems that Pete McLean removed this when he added in Tony
> Goodfellow's
> proposal for NOP auto poll (d97142r1) during A/A-4 letter
> ballot resolution.
>
> If you go back farther to earlier standards, you'll see that
> "...when a host
> performing 16-bit register accesses writes to the Drive Head
> Register, one
> byte contains the Command Register, so the drive sees a new
> command when the
> intended purpose is only to select a drive. Both drives may
> be Busy but not
> necessarily Ready i.e., Drive 0 may be ready, but not drive 1."
>
> So, there is a unique meaning to saying that a device
> supports NOP just as
> it is. This meaning can't be muddied by adding additional
> requirements. If
> you want additional requirements, you'll have to find a new
> bit in IDENTIFY
> DEVICE data.
>
> Regards,
>
> Mark Evans
> Maxtor Corporation
> 500 McCarthy Boulevard
> Milpitas, CA 95035
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Elliott,
> Robert (Server Storage)
> Sent: Monday, April 03, 2006 11:37 AM
> To: [email protected]
> Subject: [t13] ATA8-ACS NOP proposals
>
> This message is from the T13 list server.
>
>
> Stemming from some SCSI to ATA Translation (SAT) letter
> ballot discussions
> on the behavior of the NOP command, I've prepared two
> proposals for T13 to
> discuss at the April meeting (posted on
> http://www.t13.org):
>
> e06125r0-ATA8-ACS_IDENTIFY_PACKET_DEVICE_supported_features.pdf
> IDENTIFY PACKET DEVICE must return specific values for
> feature sets/commands
> that are mandatory or prohibited in packet devices (e.g.
> NOP is mandatory).
>
> e06126r0-ATA8-ACS_NOP_clarifications.pdf
> Since NOP with subcommand 00h behaves the same as an
> unsupported command,
> there is no reason for IDENTIFY DEVICE to include NOP
> Supported/Enabled bits
> except for subcommands 01h-FFh. Those subcommands have
> different behavior
> for devices supporting the Overlapped and Queued feature
> sets. So, this
> proposal adds a sentence noting that, for devices supporting
> the Overlapped
> feature set, the IDENTIFY DEVICE data bits indicating NOP
> support also imply
> that NOP subcommands 01h-FFh are supported.
>
> Also, the NOP Auto Poll model discusses how host adapters
> might complete the
> command with ERR=0, which the NOP command description doesn't
> mention at
> all. Based on d97142r1, the proposal that added the feature,
> changes are
> suggested to mention this exception in the NOP command description.
>
> --
> Rob Elliott, [EMAIL PROTECTED]
> Hewlett-Packard Industry Standard Server Storage Advanced Technology
> https://ecardfile.com/id/RobElliott
>
>
