mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Madore <david.madore@ens.fr>
To: Linux Kernel Mailing-List <linux-kernel@vger.kernel.org>
Subject: [slightly OT] what's in RAM at 0x3ffe5000 ?
Date: Sat, 13 Aug 2005 00:33:42 +0200	[thread overview]
Message-ID: <20050812223342.GA283@clipper.ens.fr> (raw)

Hi.

I have ECC RAM on my system and I wanted to check it, so (because
there doesn't seem to be any Linux ECC support for my P5WD2
motherboard) I wrote my own kernel module[#] to interrogate the
northbridge.  I was a little annoyed to find that the northbridge had
reported an ECC error, and a multi-bit uncorrectable error at that!,
at memory location 0x3ffe5000.  I cleared the error flag and ran
multiple checks and couldn't find any other error, so I stared
thinking about this address I realized that it was very near the top
of memory (I have 1GB RAM).  In fact, it is reported as "reserved" by
Linux:

BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003ff80000 (usable)
 BIOS-e820: 000000003ff80000 - 000000003ff8e000 (ACPI data)
 BIOS-e820: 000000003ff8e000 - 000000003ffe0000 (ACPI NVS)
 BIOS-e820: 000000003ffe0000 - 0000000040000000 (reserved)
 BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)

Now /dev/mem won't work that far so I can't read what's there, but I
suspect there's something very strange in that place and the ECC error
reported by the northbridge is not really an error.  Interestingly
enough, I always get an error at 0x3ffe5000 when I boot, and then
later on I get an error at 0x3fff0580.  This is consistent: I always
get those "errors" at the same memory locations, and they're always
multiple-bit errors.

So here are my questions:

* What does "reserved" mean in the BIOS physical RAM table?  Reserved
by whom?  Who owns my memory?  Do all my base are belong to him?

* What's the simplest way, under Linux (whether in userspace or in
kernel), to read the contents of a _physical_ memory location, given
that /dev/mem won't do it:

vega david ~ $ sudo dd if=/dev/mem bs=4096 count=1 skip=262117 of=/tmp/page
dd: reading `/dev/mem': Bad address
0+0 records in
0+0 records out
0 bytes transferred in 0.000118 seconds (0 bytes/sec)

* Why am I getting ECC errors in this strange place, and only there?
Do I need to worry about them?  (I mean, if it's something strange
like memory-mapped I/O I would expect the northbridge to know about it
and not report an error!)

-- 
     David A. Madore
    (david.madore@ens.fr,
     http://www.madore.org/~david/ )

[#] Source available on demand - it's pretty damn ugly, I wouldn't
want Mr. Torvalds to see it!

                 reply	other threads:[~2005-08-12 22:33 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20050812223342.GA283@clipper.ens.fr \
    --to=david.madore@ens.fr \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome