> Chris - I'll have to ponder this. Ultimately, most of this stuff
> will get covered under DIAGNOSTIC anyway (for reporting to the console
> about errors),

Actually, I disagree.  If we're listening for correctable error
reports, it is probably correct to print them (or just log them),
regardless of DIAGNOSTIC or DEBUG.

Users should be informed about hardware-related errors that the kernel
knows about.


> but I really can't quite believe that you've just
> made an argument that goes 'Disable Correctable Error Reporting
> and All Will Be Well'- which is how I have (mis?)understood your
> mail to read.

No, that's exactly what I meant.

The Green Book says unequivocally that, if correctable error reporting
is disabled, the correctable errors will be corrected automatically
(presumably by the PALcode).

I interpreted the surrounding text to mean that if reporting is not
disabled, they'll still be corrected, and that additionally the error
will be reported.  However, that interpretation may be incorrect.

If my interpretation was incorrect (and some ideas on the matter from
those more familiar with PALcode would help; Ross?), then you're faced
with a tradeoff:

	* disable correctable error reporting, knowing that (according
	  to the architecture reference) the errors will be corrected
	  properly for you.

	* keep correctable error reporting enabled, and have to write
	  platform- and cpu-specific code to correct the errors.

>From a maintenance perpective (and an "availability of documentation"
perspective), the former is very attractive.




cgd