On Thu, Nov 20, 2008 at 12:23 PM, Stefan Reinauer <span dir="ltr"><<a href="mailto:stepan@coresystems.de">stepan@coresystems.de</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><a href="mailto:svn@coreboot.org">svn@coreboot.org</a> wrote:<br>
> Author: mraudsepp<br>
> Date: 2008-11-20 13:20:35 +0100 (Thu, 20 Nov 2008)<br>
> New Revision: 1047<br>
><br>
> Modified:<br>
>    coreboot-v3/lib/ramtest.c<br>
> Log:<br>
> Be silent in ram_check in non-debug loglevels<br>
><br>
> As DBE61 support now runs ram_check for non-debug purposes and has expected failures<br>
> on DBE61A, downgrade the per-address looped fail notification printk and other messages<br>
> from BIOS_ERR to BIOS_DEBUG.<br>
><br>
<br>
</div>This patch looks odd.<br>
<br>
Why do you run the ram test at all if the debug level is below DEBUG, if<br>
none of the results are printed? Arguing with the parsable return code<br>
sounds a bit outrageous and would lead to see the same error printed<br>
twice with BIOS_DEBUG level.<br>
<br>
Wouldn't the right fix be to explicitly only check those areas that pass<br>
are not "expected to fail"?<br>
<br>
If RAM does not check, it's an error, not a debug message, and it should<br>
be printed as BIOS_ERR.<br>
<br>
If auto.c tries to check areas that are not checkable (ie vga memory),<br>
that's a bug in auto.c and should be fixed there.</blockquote><div><br>They're using ram_check for ram sizing without spd info, and don't want to print an error when one doesn't occur, so now they won't print one when one does occur either. The only way to satisfy both cases is code duplication or passing ram_check a debug level.<br>
<br>-Corey <br></div></div><br>