MMC / Mt Fuji:: NormalACA and HiSup bits in INQUIRY data are still not consistent

David Burg daviburg at windows.microsoft.com
Tue Apr 7 16:33:20 PDT 2009


* From the T10 Reflector (t10 at t10.org), posted by:
* David Burg <daviburg at windows.microsoft.com>
*
Yes this does not help much, yet :-)
So what is the host supposed to do with these bits 7-4 of byte 3? Ignore
them? Do they have any practical use given the spec confusion?
With regards,
David.
-----Original Message-----
From: Bill McFerrin [mailto:billmc37 at ctesc.net]
Sent: Tuesday, April 07, 2009 2:35 PM
To: David Burg
Cc: mtfuji5 at avc-pioneer.com; 'T10 Reflector'; Ope Aladekomo
Subject: Re: MMC / Mt Fuji:: NormalACA and HiSup bits in INQUIRY data are
still not consistent
Hi,
This is a mess that may be only esoteric. At least I hope it is.
The Host must be able to trust something as axiomatic - inviolable and
unchanging. INQUIRY data - at least some of it - should be that way.
Byte 0: Bits 4 through 0 specifies the device type (5 for MM devices)
must be in the minimum set. It has been defined in this way since SCSI-2
(1993). One could argue that it goes back to SCSI-1, but SCSI-1 did not
define a device type 5.
Byte 2: This has been "version" since SPC-2 (2001). Its original
definition as 3 separate version fields was established in SCSI-1 (1985).
SPC-2 tells us that when version = 0, the drive is claiming no
compliance with any (SPC) standard.
Theoretically, you don't need to trust anything else. As a practical
matter, the Host needs more "trustable" information, so I'll stop the
theoretical viewpoint.
The main Fuji, MMC-5 and SPC-3 disagreement is byte 3. I blew it in
MMC-5 with response data format (bits 3-0). I had requested a unique
version for MMC and I didn't get it, but I failed to fix MMC-5. This is
corrected in MMC-6. In the case of Fuji, the Host is supposed to "know"
that the device is either SCSI or ATAPI in order to determine the actual
meaning of byte 3 (bits7-4). That may be possible, but typically, USB
connected devices report as if they were ATAPI. As the editor of MMC-6,
I cannot change the field definitions of the INQUIRY data specified in
SPC-3. T10 will not permit it. I would hope for a change to Fuji, but I
that will also be difficult.
There are additional problems associated with version = 0. Luckily,
these are resolved by specifying MM device behavior.  You probably don't
care anyway. For example: the REPORT LUNS command is now mandatory
according to SPC-3. We are permitted to not implement such a useless
command when version = 0. I simply need to specify it.
Yes, this does not help much.
Cheers,
Bill
David Burg wrote:
>
> Hello,
>
>
>
> Last year I reported an inconsistency on 4 fields between MMC and Mt
> Fuji for the inquiry command response:
>
>
>
> http://www.t10.org/ftp/t10/t10r/2008/r0804024.htm
>
>
>
> The following meeting discussed and resolved the conflict on version
> and response data format fields:
>
>
>
> http://www.t10.org/ftp/t10/document.08/08-236r0.pdf
>
>
>
> However it looks like the NormalACA and HiSup bits were overlooked.
> Should these values be changed to 1b?
>
>
>
> With regards,
>
>
>
> David.
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



More information about the T10 mailing list