Date: Tue, 27 Nov 2001 09:25:29 -0800 From: Peter Wemm <peter@wemm.org> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: Wilko Bulte <wkb@freebie.xs4all.nl>, Thiemo Nordenholz <nz@thiemo.net>, Falko Meyer <wds_de@yahoo.de>, freebsd-alpha@FreeBSD.ORG Subject: Re: mprotect() takes quite long -- anyone knows this? Message-ID: <20011127172529.A5B6038FD@overcee.netplex.com.au> In-Reply-To: <15363.41389.989266.267710@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrew Gallatin wrote:
>
> Wilko Bulte writes:
> > On Tue, Nov 27, 2001 at 12:36:57PM +0100, Thiemo Nordenholz wrote:
> >
> > > > I think this can't be defective memory because this machine uses ECC-R
AM
> > > > and you would see massive ECC-errors in this case.
> > >
> > > Do you know what FreeBSD does when an ECC error is encountered? Does it
log
> > > it? Does it just silently discard the information? Can the kernel know a
bout
> > > ECC corrective actions at all? I have no clue of all that... Another
> > > information I'd be happy to get :-)
> >
> > Kernels in general can know about ECC errors. Tru64 e.g. handles them.
> > So the hardware is there. I once had dodgy memory in a AS2100A which
> > FreeBSD crashed on. But Tru64 and VMS ran on the same hardware OK.
> > This was a while ago, I'm not sure if there have been changes in
> > this area.
>
> Tru64 is smart enough not to use memory the console marked as bad, but
> we're not. I've also heard that Tru64 has a memory tester that walks
> all of physical memory at bootup and if it finds bad pages, it puts
> them aside so they don't get used. This might explain why it sits
> there for so long when it boots, but before it probes devices..
At work we have started doing this explicitly on i386 machines as we have a
huge number of deployed machines that have a broken bios that does not
initialize the ECC memory (!!!) and then programs the chipset to not
deliver the ECC event (reported as a NMI on the i386 platform). On those
boxes, the ECC system is constantly active trying to recover uninitialized
memory due to things like i686_pagezero() which reads the cache lines first
to determine if it needs to do any work to zero it. We now pre-zero the pages
and set PG_ZERO at startup, to avoid the page allocator having to zero
on demand initially. We also reprogram the chipset to turn on ECC
uncorrectable events -> NMI. This has improved things somewhat. :-)
A short while at startup can be a damn good investment if you're not planning
on booting too often.
Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011127172529.A5B6038FD>