Date: Wed, 23 Mar 2011 23:29:26 +0000 From: Alexander Best <arundel@freebsd.org> To: Andriy Gapon <avg@freebsd.org> Cc: bz@freebsd.org, Oliver Fromme <olli@lurza.secnetix.de>, freebsd-arch@freebsd.org Subject: Re: kernel memory checks on boot vs. boot time Message-ID: <20110323232926.GA17502@freebsd.org> In-Reply-To: <4D8A7841.5080004@freebsd.org> References: <alpine.BSF.2.00.1103221634241.6104@ai.fobar.qr> <201103231029.p2NATtwg090498@lurza.secnetix.de> <20110323171443.GA59972@freebsd.org> <201103231426.27750.jhb@freebsd.org> <AANLkTineBMTh3YWEO7TRGzfXHZvj80G9fw01s6z0gkRS@mail.gmail.com> <4D8A7841.5080004@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu Mar 24 11, Andriy Gapon wrote: > on 23/03/2011 21:28 Peter Wemm said the following: > > Part of the reason for this "check" is a sanity check to make sure we > > enumerated memory correctly and that we have at least got basic ram > > functionality. The existence of hw.physmem complicates this. On > > machines where hw.physmem could be used to tell the kernel that there > > was more ram present than the kernel enumerates (old bioses etc), this > > was kind of important to sanity check. > > > > Even though modern hardware will fail windows compliance tests if the > > SMAP etc is wrong, never underestimate the ability of bios makers to > > find new and bizarre ways of screwing things up. > > > > I'd kinda like to keep a basic "is this real, non mirrored ram?" test > > there. eg: the 2-pass step of writing physical address into each page > > and then checking that they are still there on the second pass. > > > > Oh, did I mention the machine where the ACPI bios info tells the OS > > that the current state is S3 (suspended to ram) instead of S0? > > > > When the kernel blows up at boot without a message.. we get the blame, > > not the bios maker. > > I hear what you are saying, but is there any other OS that takes this level of > responsibility? Should we either? > I mean, hardware and BIOS vendors can screw up things in very creative ways and > it's impossible to protect against that. When we are bug-compatible with some > other OS, then it's one thing; but when we try to to be even "better" than that, > that's quite another thing. to be honest, i suspect 99.99999999...% of RAM issues users are experiencing are issues not being detected by the current ram checks in place. these included defects or wrong bios setting (overclocking, etc.). that's why i think they are unnecessary. i kind of like how a few linux distros come up with a boot menue which lets you run memtest. if you have any suspicion that your RAM is causing issues: run memtest! ...after all: if users have the feeling the harddrive is causing problems: run smartctl! nobody expects the OS to check whether the harddrives are ok. that's what smartd is designed for. > > -- > Andriy Gapon -- a13x
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110323232926.GA17502>