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

Corey Osgood corey.osgood at gmail.com
Thu Nov 13 07:24:15 CET 2008


On Wed, Nov 12, 2008 at 10:08 PM, Mart Raudsepp <
mart.raudsepp at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081113/cf3f2cf9/attachment.html>


More information about the coreboot mailing list