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

[Mart Raudsepp]

Ühel kenal päeval, N, 2008-11-13 kell 05:08, kirjutas Mart Raudsepp:
> 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

Attached is a take on that.