On Mon, Oct 14, 2013 at 3:36 AM, Borislav Petkov <bp@xxxxxxxxx> wrote:
> On Mon, Oct 14, 2013 at 12:55:00AM -0400, Chen Gong wrote:
>> Because most of data in CPER are empty or unimportant.
>
> It is not about whether it is important or not - the question is whether
> changing existing functionality which someone might rely upon is a
> problem here? Someone might be expecting exactly those messages to
> appear in dmesg.
Pulling in a couple more people who have been touching error reporting
code in the last year or so (Hi Lance, Naveen ... feel free to drag more
people to look at this thread).
I prodded Chen Gong in to make this change because our console messages
are way to verbose (and scary) for simple corrected errors. There are 18
fields in the memory error section (as of UEFI 2.4 ... more are likely to be
added because there are issues that some of the 16-bit wide fields are too
small to handle increased internal values in modern DIMMs). Whether you
print that one item per line, or a few very long lines - it is way
more information
than the average user will ever want or need to see.
> Btw, what is the real reason for this patch, to save yourself the output
> in dmesg? If so, you can disable this output when eMCA module has been
> loaded but leave it intact otherwise.
This is an excellent idea - if the full data is being logged via TRACE, then
we can drop to virtually nothing on the console (just have something similar
to the "Machine check events logged" message so that people will get a
tip that they might want to go dig into other logs). Maybe something like:
%d corrected memory errors\n", count
[rate limited]
But we'd have to make sure that the existing user(s) of this code also
have a TRACE path.
-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
