[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-alpha
Subject:    Re: mprotect() takes quite long -- anyone knows this?
From:       Peter Wemm <peter () wemm ! org>
Date:       2001-11-27 17:25:29
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]