On Wed, Nov 12, 2008 at 10:08 PM, Mart Raudsepp < mart.raudsepp@artecdesign.ee> wrote:
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)
If you're running it in production code to detect the ram size, do you really want to send an error message after you find the (expected) end of ram? In other words, do you want to have an error message show up on every boot displaying an error message about a ram failure, and the address of that failure, that an end user (familiar only with typical BIOSes) might believe to be a bad thing?
-Corey