[MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No Event'

[keiji_katata at post.pioneer.co.jp]

Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0904081_minutes_of_the_june_1998_mt._fuji_meeting.zip">minutes_of_the_june_1998_mt._fuji_meeting.zip</a>

Hi Ai san,
My understanding was wrong. Here are two reports.
1. Meeting minutes of NEA bit
Here is a meeting minutes that NEA bit was revised from 'No Event' bit.
2. Pioneer implementation
Some Pioneer drives reports this 4 bytes "00h 02h 00 7Eh".
Best regards,
Keiji Katata
PIONEER CORP.
(See attached file: Minutes of the June 1998 Mt. Fuji meeting.zip)
Takaharu Ai <ai.takaharu at jp.panasonic.com>@avc-pioneer.com on 2009/04/08
17:36:46
mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(B
$BAw?.<T(B:	  owner-mtfuji5 at avc-pioneer.com
$B08 at h(B:  mtfuji5 at avc-pioneer.com
cc:    T10 Reflector <t10 at t10.org>, Ope Aladekomo
<Ope.Aladekomo at microsoft.com>
$B7oL>(B:  Re: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No
Event'
Hello David,
[NEA bit]
The definition of this bit in MMC is;
    If NEA (No Event Available) is set to one, the Drive supports none
    of the requested notification classes. If NEA is set to zero, at
    least one of the requested notification classes is supported.
This bit of zero indicates that the drive supports none of the Classes
requested. It is independent from the existence of an occurred Event of
one of the requested Classes.
So, we agree with your following opinion.
> This sounds more like "No Requested Class Supported".
[Response Data length]
Regarding the reported parameter length, our understanding is same as
yours.
If the NEA is set to zero, one Event Descriptor must be transferred
even if no Event has occurred. In this case, the Event Descriptor Length
field is set to 0x0006.
If the NEA is set to one, no Event Descriptor is transferred. In this
case, the Event Descriptor Length field is set to 0x0002.
Best Regards,
Harry Ai
VEBU,
AVC Networks Company,
Panasonic Corporation
Osaka, Japan
---------------- Start of the original message ----------------
>From: David Burg <daviburg at windows.microsoft.com>
>To: "mtfuji5 at avc-pioneer.com" <mtfuji5 at avc-pioneer.com>, T10 Reflector
<t10 at t10.org>
>Cc: Ope Aladekomo <Ope.Aladekomo at microsoft.com>
>Date: Tue, 24 Mar 2009 13:18:01 -0700
>Subject: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No Event'
>
> Hello,
>
> During our testing of Windows 7, our engineers noticed a difference in the
devices' implementation of GESN command response to say the same 'no event'
answer. Below is a capture of an 8 bytes answer from one device and of an 4
bytes answer from another device.
>
>
> [cid:image001.png at 01C9AC80.A5F1FA20]
>
> (Note that BusTrace incorrectly interpreted the Polled bit as Immed.)
>
> We believe this complies to MMC's:
>
> [cid:image002.jpg at 01C9AC80.A5F1FA20]
>
> (One might want to be careful to clarify "If no event of the requested
notification class has occurred, ..." because event may occur in another
class
and yet can't be reported.)
>
> The other device responds:
>
> [cid:image003.png at 01C9AC80.A5F1FA20]
>
> This does not seem allowed by the current spec, although it is not
completely
obvious.
>
> Also, some software engineers thought they would get NEA = 1b and 4 bytes,
based on the name of that bit "Not Event Available". From an English language
point of view, there is indeed no event available. However, the spec
definition
of the bit then contradicts with what one would expect out of English
language
alone:
>
> "If NEA (No Event Available) is set to one, the Drive supports none of the
requested notification classes. If NEA
> is set to zero, at least one of the requested notification classes is
supported."
>
> This sounds more like "No Requested Class Supported".
>
> So, Microsoft believes this GESN section should be reviewed in detail and
clarified.
>
> With regards,
>
> David.
>
----------------- End of the original message -----------------