On N, 2008-11-13 at 03:14 +0100, Carl-Daniel Hailfinger wrote:
On 13.11.2008 02:43, Peter Stuge wrote:
Carl-Daniel Hailfinger wrote:
Be less noisy in ram_check in non-debug loglevels
I'm not so totally sure we really want this change. I won't veto it, but I think RAM test errors should always be shown with full verbosity.
Because the result is really meaningless in the general case I like the patch.
You managed to snip my suggested solution when you quoted my mail. Here it is again for your convenience:
If it is really needed, you could add another parameter to ram_check which specifies the log level.
I'd actually go as far as rip out the last printk too, or rather always have it BIOS_DEBUG, not BIOS_ERR when it fails. Rationale is the following:
ram_check has three viable use cases that I can think of:
a) During development as a local addition of a call to it while doing memory timing fixing and work b) To do automatic memory sizing a la DBE61 c) To react somehow to memory failure, perhaps disabling one DIMM out of multiple or loading a payload that runs in CAR that instructs the user to fix his RAM or whatever.
b) and c) means its used in production code that shouldn't be spitting all this failure spam into serial, but instead the return value of ram_check should be checked by the caller and reacted upon (goes together with the warn_unused suggestion)
a) means it's done during development, in which case the developer better already have BIOS_DEBUG or BIOS_SPEW selected.
Besides, as the documentation of ram_check code itself says - it is "is my RAM properly configured" test, not a "is my RAM faulty" test. So what relevance do the exact verbose read failures have in a production builds console output (for b and c case, but especially b)?
So all that put together, I don't see a case where the exact failure location and their values should be spammed to console with less verbose loglevel than DEBUG.
Regards, Mart Raudsepp