From: ebiederm@xmission.com (Eric W. Biederman)
To: Chiaki <ishikawa@yk.rim.or.jp>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Q: boot time memory region recognition and clearing.
Date: 14 Jul 2002 02:20:38 -0600 [thread overview]
Message-ID: <m14rf2ra95.fsf@frodo.biederman.org> (raw)
In-Reply-To: <3D303700.5030002@yk.rim.or.jp>
Chiaki <ishikawa@yk.rim.or.jp> writes:
> >> I have found that the particular motherboard (and memory sticks)
> >> that I use at home tends to generate bogus memory problem warning messages
> >> when I use ecc module.
> >> Motherboard is Gigabyte 7XIE4 that uses AMD751.
> >> (Yes, AMD has now provides AMD76x series chipset for
> >> newer CPUs.)
> >> I say "bogus" because I have tested the hardware
> >> many times using memtest86 and found that it doesn't
> >> detect any memory errors even
> >
> >memtest86 isnt (except on the very very latest versions) aware of ECC.
> >It sees the memory after the ECC rescues minor errors so if the RAM has
> >
> >errors but ECC just about saves you it will show up clean
> >
> Thank you for the info on the latest memtest86.
> I will check out.
>
> It might as well be the case that memtest86 (previous versions)
> was not quite ECC-aware.
>
> I was not clear on the type of error messages
> I received from ecc.o module.
> I got both SBE (single bit error detected and corrected)
> and MBE (multiple bits error detected,
> which presumably was not correctable!).
>
> My point was that there is something amiss
> if memtest86 doesn't report errors due to
> underlying (hardware) ECC fix,
> but the why ecc.o module does.
>
> In any case, I will run memtest86 (the latest version).
> Thank you again for the info.
Note. The hardware ECC support in memtest86 3.0
is limited, so I would check to make certain your chipset
is supported..
> But any comment to my original post and other avenue
> to achieve similar result welcome.
> (Maybe the high reliability computing people
> have a better idea short of replacement BIOS or
> even have some prototype code working on this?
> Hmm. Come to think of it, maybe I can take
> the part of free BIOS and see if it will not
> enlarge setup.S too large, etc.. But thinking of
> various proprietary chipsets, I would hope that
> I can insert a short C routine somewhere in the
> boot chain, preferably on the kernel side, to
> accomplish my objective.)
Your objective is misguided. Even with a bios that
is slightly buggy in initializing the ECC bits, what you want is
scrubbing. Then if the error disappears after 5 minutes of uptime
you can ignore it. And if it comes back you know you really have
something to worry about. At least for single bit errors this should
fix the whole problem with something that is useful for other
purposes.
Eric
next prev parent reply other threads:[~2002-07-14 8:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-13 14:19 Q: boot time memory region recognition and clearing Chiaki
2002-07-14 8:20 ` Eric W. Biederman [this message]
2002-07-14 15:38 ` Ishikawa
2002-07-14 20:26 ` Eric W. Biederman
-- strict thread matches above, loose matches on Subject: below --
2002-07-18 2:08 Chiaki
2002-07-13 23:27 Chiaki
2002-07-13 10:08 Ishikawa
2002-07-13 14:15 ` Alan Cox
2002-07-13 15:09 ` Rogier Wolff
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=m14rf2ra95.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=ishikawa@yk.rim.or.jp \
--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