All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Bligh <mbligh@google.com>
To: Tim Hockin <thockin@google.com>
Cc: Ken Harrenstien <klh@google.com>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [kernel-reviewers] a small code review (2414483) Automated g4 rollback of changelist 2396062.
Date: Wed, 26 Apr 2006 10:36:54 -0700	[thread overview]
Message-ID: <444FAFB6.4070303@google.com> (raw)
In-Reply-To: <20060426173225.GB28519@google.com>

Tim Hockin wrote:
> On Wed, Apr 26, 2006 at 10:12:14AM -0700, Ken Harrenstien wrote:
> 
>>That doesn't work because IIRC it only reports the amount of memory
>>the kernel has been told (eg via "mem=") to manage in a certain sense,
>>not how much is actually physically available.
>>
>>The I2 netboot kernel would really REALLY like some exported /proc
>>values that accurately report physical memory (if nothing else, the
>>number of DIMMs and their sizes).  It has to figure this out in order
>>to install the proper kernel with proper LILO command-line args.
> 
> 
> The kernel can't really know how much memory is in the system without
> getting chipset-specific.
> 
> MTRR is a good way to hazard a guess, and will probably be right, but as
> you indicated, BIOS vendors have historically been REALLY bad about
> MTRRs.  Better now, but bad a few years ago.
> 
> SMBIOS (on our boards) *does* accurately report the number of DIMMS and
> their sizes (and more!).  But it only works on Google BIOS.

cc: linux-kernel
bcc: kernel-reviewers

Are you saying our e820 maps and srat tables are wrong? that's a little
worrying ...

M.

       reply	other threads:[~2006-04-26 17:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <444F0729.2020407@google.com>
     [not found] ` <444F0A94.70100@google.com>
     [not found]   ` <6599ad830604252300m27db3d20j39beafbe09788824@mail.google.com>
     [not found]     ` <444F1218.6020601@google.com>
     [not found]       ` <6599ad830604252334yd6d933w5386dccb4af4b971@mail.google.com>
     [not found]         ` <444F9777.9090704@google.com>
     [not found]           ` <444F989B.3040900@google.com>
     [not found]             ` <444F9E2B.40704@google.com>
     [not found]               ` <444FA2BB.2070908@google.com>
     [not found]                 ` <Pine.LNX.4.56.0604261002430.4623@minbar.corp.google.com>
     [not found]                   ` <20060426173225.GB28519@google.com>
2006-04-26 17:36                     ` Martin Bligh [this message]
2006-04-26 17:43                       ` [kernel-reviewers] a small code review (2414483) Automated g4 rollback of changelist 2396062 Tim Hockin
2006-04-26 18:24                       ` Andi Kleen

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=444FAFB6.4070303@google.com \
    --to=mbligh@google.com \
    --cc=klh@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thockin@google.com \
    /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.