All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wakko Warner <wakko@animx.eu.org>
To: David Ronis <ronis@ronispc.chem.mcgill.ca>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Memory not being reported
Date: Thu, 22 Jan 2009 17:27:04 -0500	[thread overview]
Message-ID: <20090122222704.GA27575@animx.eu.org> (raw)
In-Reply-To: <1232658295.3455.7.camel@ronispc.chem.mcgill.ca>

David Ronis wrote:
> I'm running 2.6.28.1 on an i686 (slackware-12.1 for the most part) box.
> I recently added some extra memory, expanding from 2Gb to 4.  Everything
> works as expected except that not all of the memory seems to be seen.

I'm running on 2.6.24.3 right now which is irrelevent.  Is your system
x86_64 capable?  This specific machine is not.  It's an older dual xeon 533mhz
fsb.

> free returns:
> 
>              total       used       free     shared    buffers
> cached
> Mem:       3374860    2099504    1275356          0      86612
> 1032024
> -/+ buffers/cache:     980868    2393992
> Swap:       497972          0     497972

             total       used       free     shared    buffers     cached
Mem:       4019196    1342956    2676240          0     405712     223672
-/+ buffers/cache:     713572    3305624
Swap:            0          0          0


> On the other hand, user-space tools like lshw show the 4 1Gb DIMMS as
> does the BIOS configuration boot menu.

lshw IIRC uses dmi information to obtain that information.

> One suspicion is that the configure option CONFIG_HIGHMEM4G=y
> should be unset and the CONFIG_HIGHMEM64G  should be.

# grep HIGH .config
# CONFIG_HIGH_RES_TIMERS is not set
# CONFIG_NOHIGHMEM is not set
# CONFIG_HIGHMEM4G is not set
CONFIG_HIGHMEM64G=y
CONFIG_HIGHMEM=y
# CONFIG_HIGHPTE is not set
# 

I see no reason not to use highmem 64gb  I've used it on several of my
systems, even ones that can't handle more than 2gb w/o problems.

One thing I have noticed (which is irrelevent to your question) is that I
see about 100mb less memory running a 64-bit kernel vs a 32-bit kernel on 2
systems (different brand of motherboard) and 4gb.  One was upgraded to 8gb;
32-bit shows about 8400000kb memory and running 64-bit shows about 8200000kb
memory.  Noone has answered my question as to why that is.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
 Got Gas???

  reply	other threads:[~2009-01-22 22:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-22 21:04 Memory not being reported David Ronis
2009-01-22 22:27 ` Wakko Warner [this message]
2009-01-23 12:44 ` markus reichelt
2009-01-24  8:37 ` Robert Hancock
2009-01-25 17:13   ` David Ronis
2009-01-25 20:10     ` Robert Hancock

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090122222704.GA27575@animx.eu.org \
    --to=wakko@animx.eu.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ronis@ronispc.chem.mcgill.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.