ZPODD Drive Issues Microsoft Corp. and Intel Corp.

Not all drive loading mechanisms support LoChange event of Device Busy Class Example many slot loading ODDs do not support LoChange event ZPODD section does not clearly state which loading mechanisms should implement LoChange event The spec says host may look for end of loading operation only for Drawer, Tray or Pop-up lid (2 nd paragraph after Table 868) Impact ZPODD functionality will not work on non-complaint drives as we rely on LoChange event for all loading mechanisms Possible Solutions Implement LoChange in all ODDs Develop alternate mechanism to detect media removal, like polling. But note that this solution would break Asynchronous Notification. Recommended solution All ZPODDs should implement LoChange event Issue #1

Issue #2 Incorrect LoChange implementation Some drives report Busy status of Lochange event followed by NotBusy status of Change event Sometime only Busy status and not NotBusy status Impact ZPODD solution will not work with these ODDs Possible Solutions Use alternate mechanism other than LoChange ODD FW should be fixed Recommended Solution This is a bug and should be fixed in ODD FW. Discuss Fig 221. ODD should report Busy LoChange at start of loading/unloading operation followed by NotBusy LoChagne at end of loading/unloading operation

Issue #3 Inconsistent BUSY implementation Not all drives report BUSY on tray eject (open or close) requests Drives don’t consistently report BUSY on media events (like reporting BUSY while media is being detected) Impact Driver may be fooled into turning off ODD while it is busy detecting media Some drives report “media not present” while media is detected. If the ODD does not report BUSY then driver may be fooled into turning it off Very bad user experience resulting in “Denial of Service” Possible Solutions There is not much that driver can do if the ODD FW behaves incorrectly Recommended Solution We would like Fuji Group to tell us how to go about it Spec should specify that BUSY status is reported for all tray and media events. We may want to add it to ZPODD section for clarity or at-least point to correct Fuji Section

Issue #4 Some drives report LoChange on first eject command after power-on, but not on others Inconsistent implementation Impact ZPODD functionality will not work end to end Bad user experience where idle drives may not be powered off Possible Solutions Not much that driver can do other than not relying on LoChange Recommended Solution Spec should clearly state that LoChange should be reported for all manual loading and unloading operations

Issue # 5: Incorrect GESN implementation ODD supports Media Event Class of GESN but reports something else Device reports support of Media Event Class in the Supported Event Class field in the event header, but when receiving a GESN command only requesting Media Notification Class (only Media bit is set in the Notification Class Request field), NEA field is set to 1 in the returned event header. Impact Driver can’t reply on Media Event Class of GESN to get the media status Possible Solutions Use TUR command to get sense code It is a bug and certainly needs to be fixed Could we use Busy and NotBusy status of Device for it? Recommended Solution Bug and has to be fixed ZPODD Mt. Fuji Spec should include TUR command as an equally possible alternative Mention in ZPODD section that host may send GESN command requesting only Media Class events so that ZPODD drive FW engineers test this use case

Issue # 6: Incorrect GESN Implementation This is continuation from previous slide A retry with the same command parameters as mentioned on slide 4 returns NEA=0 but the returned event is an operational event, not the requested media event. Impact Same as Issue #5 Possible Solutions Same as Issue #5 Recommended Solution Same as Issue #5

Issue #7 Inconsistent sense code is reported It is not clear what sense code should be reported by ODDs with different loading mechanisms after media is ejected Impact ODD may not be turned off even if it has the capability Possible Solutions Use the word “shall” and not “may” Recommended solution Use the word “shall” and not “may”

Issue #8 Change event is missing in ZPODD Section Change event is expected to be reported by ODD on software loading/unloading operation Impact The drive will not work as a Zero Power capable ODD Possible Solutions Include it in ZPODD section Use alternate mechanism Recommended Solution ZPODD section should specify it clearly and also call out how to check if ODD supports it It should be made mandatory for all ZPODD drives like LoChange ODD FW should be verified to not have same bugs as LoChange

Issue #9 Incorrect media status being reported Drives (from various manufacturers) do not report media insertion problems consistently Some drives report “Media Not Present” in media status GESN if it takes longer than usual to detect the media. Impact It is a bad user experience and device would be powered down with media in it Possible Solutions This should be fixed and addressed in spec as device would be powered down incorrectly Would it be possible to use GESN to report media insertion failures (e.g.: upside-down media) Are there alternate commands for this? TUR? Recommended Solution Mt Fuji committee should make suggestion on how a consistent implementation can be achieved

Issue #10 DBML bit not supported correctly Not all drives report DBML = 1 in Loading Mechanism Type field (Removable Medium Feature Descriptor) Impact The ODD would not be detected as ZP capable and ODD will not function as ZP capable device Possible Solutions Fix the FW BUG Recommended Solution It must be supported by all ZPODD drives Spec to be updated, if necessary, to address it

Issue #11 ZPODD is in informative section Appendix K viewed as a “suggestion” and not required behavior to allow ZPODD to function properly Impact If it is not normative, ODD FW may or may not implement ZPODD requirements Possible Solutions Add relevant things from ZPODD section to normative section Make ZPODD normative It should be moved to normative section Recommended Solution Make appendix K a normative section

Issue #12 Media Status events not reported consistently No Media Status events are reported on loading/unloading operation Not receiving Media Status GESN response after GESN command sent with “Immed “ = 0 Impact If BUSY Change/LoChange event handling is not fixed, then resolving this issue becomes paramount Forces host to poll with explicit Media Status GESN to get media status update Notification Class Request Value = 0x10 Possible Solutions Fix issues 1-4 Change host software to periodically poll with explicit Media Status GESN. Polling will break Asynchronous Notification Recommended Solution Fix issues 1-4

Issue #13 Effect of Prevent/Allow on Media Status GESN events Comment at last Mt.Fuji meeting indicated that Media Status events are not reported when Persistent/Prevent bit is set in a “Prevent Allow Medium Removal” command. Text is unclear on this point Impact Media Status GESN behavior may not be consistent, nor hosts use of Media Status be reliable if specification is not clear. Possible Solutions Topic should clarify “Morphing Operation” in “Features” section. Recommended Solution Clarify behavior in specification and discuss with Mt. Fuji group

Issue #14 Change event not reported with Immed bit set to 0 This was a comment from Mt Fuji group in Jan’11 meeting Impact Change event would not be reported if Asynchronous Notification is used ZPODD functionality would break if software loading/unloading operation is used Possible Solutions Periodically poll for media status but that would break Asynchronous Notification Change event should have parity with LoChange event and spec should be modified to maintain parity Recommended Solution Modify spec and maintain parity with LoChange event

BACKUP SLIDES