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

Takaharu Ai ai.takaharu at jp.panasonic.com
Thu Apr 9 00:10:28 PDT 2009


* From the T10 Reflector (t10 at t10.org), posted by:
* Takaharu Ai <ai.takaharu at jp.panasonic.com>
*
Hello Katata-san,
Thank you for the important information.
> 1. Meeting minutes of NEA bit
> Here is a meeting minutes that NEA bit was revised from 'No Event' bit.
According to this minutes, The Notification Vlass field of 000b was
changed from "None of the requested event classes are supported" to
"Reserved". This decision was reflected to Fuji3v60.pdf. But later,
Fuji3v092.pdf, the definition of this value was returned to the original
one without any voting, maybe.
Form the theoretical point of view, this value should be Reserved
because the Notification Class 0 is Reserved and may be used for any
purpose in future. At that time, the value 000b must be used to report
the Class 0 event.
NEA was defined to report "None of the requested event classes are
supported" as the same meaning of the original definition of 000b of
Notification Vlass field.
I think we should discuss that the definition of the Notification Class
000b should be returned to Reserved or not.
Best Regards,
Harry Ai
VEBU,
AVC Networks Company,
Panasonic Corporation
Osaka, Japan
---------------- Start of the original message ----------------
>From: keiji_katata at post.pioneer.co.jp
>To: mtfuji5 at avc-pioneer.com
>Cc: T10 Reflector <t10 at t10.org>, Ope Aladekomo <Ope.Aladekomo at microsoft.com>
>Date: Thu, 9 Apr 2009 13:45:36 +0900
>Subject: Re: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No
Event'
>
> 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 -----------------
> 
> 
> 
> 
----------------- End of the original message -----------------
*
* 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