From: Robert Snively X3T9.2/90-89 Rev 0 Sun Microsystems, Inc. 2550 Garcia Avenue Mountain View, CA 94045 To: John Lohmeyer Chairman, X3T9.2 3718 N. Rock Road Wichita, KS 67226 Date: June 15, 1990 Subject: Proposed requirements for Diagnostic Command Set Dear Mr. Lohmeyer: The Diagnostic Command Set proposals that have been presented to the com- mittee were reviewed by technical contributors within our company. They agreed upon the following recommendations about the command set. These recommendations define certain desirable characteristics of the command set and identify pitfalls which should be avoided in creating such a command set. We hope that these prove helpful to the committee in its considerations. 1) The complete DCS, if implemented, allows the SCSI software to de- stroy the disk's capability of formatting, including the destruction of defect in- formation, system information, and the writing of information off-track. While useful during the disk manufacture process and the evaluation period, this ca- pability is very dangerous to allow in machines that are shipped to end users. Sun recommends that the full DCS capabilities not be made available in ma- chines installed in the field. The DCS can be reinstalled for repair actions us- ing the firmware download capability or by installing a repair EPROM. 2) Some of the diagnostic commands are presently available in the stan- dard SCSI command set. The DCS should be a natural extension of the SCSI command set, using Diagnostic pages to invoke the functions not already pro- vided by the standard command set. 3) Some of the diagnostic commands allow the destruction of data or the disk's basic format. Incidentally, this is also true of the standard command set. It was felt that a keyword could provide only very limited protection. More ef- fective protection requires the use of trusted programs that do not execute de- structive sequences and the removal of some of the most dangerous commands from the command set for devices shipped to end users. 4) A number of DCS functions are proposed that will allow the setting of abnormal read channel states and will allow the operation of both reads and writes off-track. The increased integration levels of new drives are making some of the read channel parameters less available. Embedded servos are mak- ing off-track operation less interesting as a variable. In all cases, the parameter values have different meanings for different drives. After considering a num- ber of interpretations that may be associated with those parameter values, Sun contributors felt that actual values for the parameters should be used, not nor- malized or symbolic values. This allows the device's behavior to be calibrated against the device's specification. Obviously, different devices will allow the use of different parameter values and value ranges. A new error code should be provided to indicate when unimplemented or illegal parameter values are se- lected for a particular device. The error code would be "Illegal Diagnostic Pa- rameter Value", with perhaps some additional sense code qualifiers to further define the problem. 5) The DCS proposes that the Mode Select parameters can be set to a pre- cise value instead of rounded to the best advisable value. Instead, the DCS should be limited to the acceptable values already defined and definable for the Mode Select, since for those cases where rounding or advisory use is made of the information, the usual reason is that values other than the values select- ed by the target are not meaningful or implemented. Appropriate error messag- es are already available to manage this condition. 6) The DCS proposes the capability of modifying the actual gap and sync- ing structure of the sector. Those values are so strictly structured into the be- havior of the controller that modifying gap sizes, syncing fields, and identifier fields is usually not meaningful. There is a chance that the evaluation of some removable media devices and some unusual disk devices may be slightly more complete if this capability is available during the evaluation process, but it should not be available in the field. 7) Many of the new disk devices have cylinders reserved for disk private functions, including the saving of read/write channel parameters, defect infor- mation, and disk firmware. Sun Microsystems contributors believe that the in- formation should be available under those DCS commands that perform read operations. The information should not be accessible with write instructions except during the manufacturing and evaluation period. Again, the firmware required to write those areas should probably only be available by down load- ing. 8) Some proposals for major SCSI protocol violations under the DCS have been discussed by the committee. Those would make it impossible to run DCS under a standard Host Adapter. Instead, the Send Diagnostic Command in- struction should be used to supplement standard commands and other diagnos- tic commands. All the protocols should meet the present standard. In some cases, that may require two-command sequences to first transmit some com- mand and control information followed by a later transmission or reception of the associated data. The two command sequence is not a an efficiency problem during the evaluation and diagnostic operations. 9) The use of multiple initiators during diagnostics is not considered by the DCS. The RESERVE/RELEASE protocol will be sufficient to allow the di- agnostic utilities to capture and later release a machine for diagnostic purpos- es. Element Reservation or Extent Reservation may be required on some targets, including Medium Changer Devices, to avoid locking up an entire storage subsystem for the diagnosis of a single portion of the system. 10) Access by physical sector is proposed. There is no reliable way to de- termine that the "correct" physical sector is actually provided. Some physical sectors that have been spared because of defects may be unrecoverable and may in fact render subsequent sectors of a multi-sector operation unrecover- able. Sun recommends that the sector be recovered on a best effort basis with the understanding that the best effort may very well be not good enough. Ap- propriate error indictions are required. 11) Access to the entire sector contents, including the ID field and all flags and ECC is proposed. Some of these parameters are proprietary, some are not available through the disk controller implementation, and at least some ECC's may remove some redundant bits on the fly. Sun believes that read access to all data, including the ID field, data field, and ECC characters should be available at least in the commands available for evaluation. Write access beyond the present Write Long is not presently a requirement. The read access assists in the debugging of sparing algorithm problems and similar activities during the evaluation process. 12) A DC erase and a "high-frequency" erase are proposed. These could theoretically be used to re-identify defects and to locate track servoing prob- lems. In fact, they are most useful to the designers and manufacturers of the disks. These are capabilities that Sun will sometimes find useful during the evaluation process when disk failures are being investigated. The capability should not be provided in machines shipped to end users. 13) A track format, cylinder format, and sector format capability are sug- gested. These all have the capability of creating invalid formats which will re- quire a total reformatting of the disk. While sometimes useful during the evaluation and the repair process, the capability should not be allowed on ma- chines shipped to end users. The functionality previously associated with sec- tor and track level formatting is now performed by the reassign blocks command. Sun will not be supporting any of these functions except through specialized application programs and diagnostic utilities. If possible, it is desirable that a similar command set be provided for all types of SCSI devices. Some additional functions that might be interesting include: Capability to margin drive speed. Specification of pre-coded exercise routines, including seek time verification, random verification of data locations, and a disk surface verify capability. These could provide logged error information. I hope that these concepts and directions prove to be useful guidelines for the design of the Diagnostic Command Set. Sincerely, Robert N. Snively Member, X3T9.2