Informational exceptions control page

Gene Milligan Gene_Milligan at
Fri Aug 11 14:04:16 PDT 1995

I have a few comments regarding section 8.3.3 of SPC and a proposal for an 
enhancement. First the comments:


(1) As I recall the first working meeting on this subject there was a consensus 
that the new page would not only be useful for the 5Dh case but for other more 
general unsolicited exceptions. That is why the page has a different name than 
the 5Dh condition.

Consequently I take exception with the last sentence of the first paragraph 
that "This page shall only apply to informational exceptions that report an 
additional sense code of FAILURE PREDICTION THRESHOLD EXCEEDED to the 
application client." I agree that the statement  could be applicable to the 
Perf, DExcpt, and LogErr bits. However the MRIE field would seem to have 
applicability to other exceptions and making it dedicated to 5Dh seems 
questionable to me.

(2) The text and Table do not agree on the capitalization of the DExcpt (if the 
table is correct) bit.

(3) In Table 86 does the 4h method imply that if a 5Dh condition exists and all 
subsequent commands are unrecoverable that the target shall not ever report 5Dh?

(4) For a drive with a 5Dh condition, what is the response to a Request Sense 
poll with methods 1h-5h set?

(5) "access" in the only sentence of the last paragraph should instead be 
"across". (Even though that is probably not elegant grammar I think it does 
correctly convey the requirement.)

(6) Shouln't the page length be (0Ah) rather than (0Eh)?

Proposed enhancement:

The Informational Exceptions Control Page determines how S.M.A.R.T. 
(Self-Monitoring Analysis and Reporting Technology) reports an exception 
condition when drive failure is predicted.  Two questions deserve additional 
consideration.  How should a drive manufacturer test the exception reporting 
mechanism when the drive is operating fine ?  How would an operating system 
developer test his/her response code when an exception reporting condition will 
probably never occur during test?  

A simple analogy, you install an alarm system in your house.  Do you wait for a 
burglar to break into your house to see if the alarm goes off ?  Not likely, 
you would want to occasionally verify that it still works. 

A proposed mechanism is to activate an exception condition for debug/testing 
purposes by setting (Byte 2, Bit 2) in the Informational Exceptions Control 

A TEST bit of one would create a false drive failure at the next interval time 
(as specified in bytes 4-7) if the DExcpt (byte 2 bit 3) is not set.  The 
Reporting Method (byte 3 bits 0-3) and Report Count (bytes 8-11) would apply as 
specified in the original IEC Mode Page document.  The false drive failure 
would be reported as sense code/qualifier 5DFFh (FF for false failure versus a 
true failure 5D00h).  A TEST bit of zero would instruct the drive to not 
generate any false drive failure notifications.

           Table 85 - Informational exceptions control page
|  Bit|   7    |   6    |   5    |   4    |   3    |   2    |   1    |   0    |
|Byte |        |        |        |        |        |        |        |        |
| 0   |   PS   |Reserved|         Page code (1Ch)                             |
| 1   |                           Page length (0Ah)                           |
| 2   |  Perf  |         Reserved         | DExcpt | TEST   | Reserv | LogErr |
| 3   |             Reserved              |               MRIE                |
| 4   | (MSB)                                                                 |
|- - -+- -                        Interval timer                           - -|
| 7   |                                                                 (LSB) |
| 8   | (MSB)                                                                 |
|- - -+- -                        Report count                             - -|
| 11  |                                                                 (LSB) |

(If table distorted by E-Mail convert font to Courier New 8)

I would prefer to discuss this by the reflector since a conflict prevents me 
|from attending the next SCSI-3 working group and plenary meetings (they have 
the opportunity to be shorter). However I would appreciate it if some kind sole 
caries this into both (after any necessary reflector massaging) and gets it 
voted into SCSI-3.


More information about the T10 mailing list