[coreboot] [PATCH 5/5] Be less noisy in ram_check in non-debug loglevels

Mart Raudsepp mart.raudsepp at artecdesign.ee
Thu Nov 13 04:08:11 CET 2008


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





More information about the coreboot mailing list