From: Andi Kleen <ak@suse.de>
To: Martin Bligh <mbligh@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: 26 Apr 2006 20:24:13 +0200 [thread overview]
Message-ID: <p731wvk8ab6.fsf@bragg.suse.de> (raw)
In-Reply-To: <444FAFB6.4070303@google.com>
Martin Bligh <mbligh@google.com> writes:
> 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.
Actually quite a lot of SMBIOS report DIMMs more or less correct.
It works even on my laptop.
I implemented support for it in the latest mcelog (--dmi). Not all
and a few big names screw it up (in particular the mappings from
address range to interleave set). But overall it looks surprisingly
good so far.
-Andi
prev parent reply other threads:[~2006-04-26 18:24 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 ` [kernel-reviewers] a small code review (2414483) Automated g4 rollback of changelist 2396062 Martin Bligh
2006-04-26 17:43 ` Tim Hockin
2006-04-26 18:24 ` Andi Kleen [this message]
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=p731wvk8ab6.fsf@bragg.suse.de \
--to=ak@suse.de \
--cc=klh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@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.