Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 Jul 2000 08:21:45 -0700 (PDT)
From:      Jin Guojun (DSD staff) <jin@george.lbl.gov>
To:        arubin@concentric.net, msmith@FreeBSD.ORG
Cc:        freebsd-hardware@FreeBSD.ORG
Subject:   Re: Asus K7V with Crucial PC133 ECC RAM
Message-ID:  <200007121521.e6CFLjQ22630@portnoy.lbl.gov>

next in thread | raw e-mail | index | archive | help
I do not think there is any thing to do with memory chips, but the O.S.
By carefully tested on many systems with different CPU, M/B and memory,
I found that this happenes on all systems we have here with running 4.x
or CURRENT.  The real memory is 12kB to 16kB less the BIOS says.
Attach another disk with 2.2.8 and 3.5 does not have such phenomena.

A wild guessing is that either 4.x or later reports real-real availiable
amount to the system, or the new bus system intends to do so. Maybe someone
from the coreteam can tell what is the true story.

	-Jin

> Ahh, yes.  Well, in this case the amount of memory 'lost' is indeed 
> inversely proportional to the quality of your RAM.  The better your RAM, 
> the less capacity that's lost through various coupling issues.  You can 
> also improve things by rotating your RAM regularly, and cleaning the 
> contacts with fine wet-and-dry sandpaper every couple of months to reduce 
> oxidation.  Also you may find that as your RAM is "broken in" it will 
> regain a little capacity - using a "RAM exerciser" program here can help.
> 
> Of course, the law of diminishing returns applies as well; spending 
> twice as much on RAM isn't going to result in RAM that only "loses" half 
> as much - there's some "RAM loss" that's just inevitable.  Orientation of 
> the system is also important - and if you're really unlucky you can end 
> up with RAM that's designed for use in the southern hemisphere.  Due to 
> the manufacturing processes there's always more of it than the northern 
> hemisphere type so the chip makers tend to try to dump it into the channel.
> 
> Typically the sort of "loss" you're seeing (0.03%) is considered quite 
> acceptable - I'd expect that you can probably soak up at least 10x this 
> with an Enlightenment theme or a neat desktop sound scheme.
> 
> > I just realized there is an error in my original post.  The system reports
> > 262144K with 256MB installed.  This means FreeBSD always reports 80K less.
> > 
> > ----- Original Message -----
> > From: "Greg Lehey" <grog@lemis.com>
> > To: "Mike Smith" <msmith@FreeBSD.ORG>
> > Cc: "Anthony Rubin" <arubin@concentric.net>; <freebsd-hardware@FreeBSD.ORG>
> > Sent: Tuesday, July 11, 2000 10:07 PM
> > Subject: Re: Asus K7V with Crucial PC133 ECC RAM
> > 
> > 
> > > On Tuesday, 11 July 2000 at 18:00:55 -0700, Mike Smith wrote:
> > > >> I recently put together a system that uses the Asus K7V motherboard
> > with
> > > >> Crucial PC133 ECC RAM.  I bought 2 128MB DIMMs.  The BIOS is seeing the
> > RAM
> > > >> correctly as 264144K, but FreeBSD has 262064K listed under real memory.
> > I
> > > >> thought this was odd and wanted to make sure one of the DIMMs wasn't
> > bad so
> > > >> I removed both and then tried one at a time.  No matter which DIMM I
> > use and
> > > >> which slot I put it in the BIOS sees 131072K and FreeBSD sees 130992K.
> > The
> > > >> only other thing that is strange about this setup is that the K7V BIOS
> > > >> currently has a known problem when you enable ECC so ECC is currently
> > > >> disabled on my board.  Below is the portion of dmesg I am referring to.
> > > >>
> > > >>> dmesg | grep memory
> > > >> real memory  = 268353536 (262064K bytes)
> > > >> avail memory = 256950272 (250928K bytes)
> > > >
> > > > There's nothing wrong with your RAM - some of it is being used by the
> > > > kernel.
> > >
> > > I think he's referring to the 80 kB that don't show up in real
> > > memory.  I'd assume that's the BIOS.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hardware" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200007121521.e6CFLjQ22630>