Ü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. -- Mart Raudsepp
0001-Be-silent-in-ram_check-in-non-debug-loglevels.patch
Description: application/mbox
-- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
