From: Mauro Maroni <mmaroni@fi.uba.ar>
To: gentoo-amd64@lists.gentoo.org
Subject: Re: [gentoo-amd64] Re: coreutils-6.4 - cannot compile
Date: Sat, 11 Nov 2006 17:54:20 -0300 [thread overview]
Message-ID: <200611111754.20353.mmaroni@fi.uba.ar> (raw)
In-Reply-To: <eiv183$c3f$1@sea.gmane.org>
On Thursday 09 November 2006 07:51, Duncan wrote:
> Mauro Maroni <mmaroni@fi.uba.ar> posted
> 200611082025.25462.mmaroni@fi.uba.ar, excerpted below, on Wed, 08 Nov
>
> 2006 20:25:25 -0300:
> > Well, then I got segfaults compiling other packages, and a couple of
> > times the machine freezed doing trivial things like browsing the web.
> > Could this be a hardware issue? RAM seems to be OK as I ran memtest
> > during the night and did not show any error after 9 hours.
>
> That's a classic hardware issue, yes. The cause can be one of several
> things. Note that there are at least two ways RAM can be bad and memtest
> checks only one -- memory actually corrupting in storage. From hard
> experience, I know the other one all too well -- AND know that memtest
> doesn't catch it AT ALL. That one is memory timing issues, and as
> memory speeds increase, it's becoming more and more common. Taking my
> case as an example, the RAM was rated PC3200, but simply wasn't stable at
> that. Unfortunately, my mobo was new enough at the time, and using the
> then new AMD64 memory-controller-on-CPU technology, that the BIOS didn't
> have the usual memory speed tweaking options. After fighting with it for
> some time, a BIOS upgrade was eventually made available that added these
> options, and a very simple (with the right BIOS option) tweak to reduce
> memory clocking from the rated PC3200 (200 MHz DDRed to 400, times 8 bit
> bus width, equals 3200) to ~PC3000 (183 MHz DDred to 366, times 8, rounds
> to 3000) eliminated the issue entirely. The system was then rock-stable,
> even after tweaking some of the detailed individual wait-state settings
> back up to increase the performance a bit from the defaults.
>
> So, before you eliminate memory as a possibility, check your BIOS and try
> declocking it a notch or two.
It has been very stable during the last days. But I will give this a try if
the problem comes back. Thanks a lot for your answer.
Mauro
--
gentoo-amd64@gentoo.org mailing list
prev parent reply other threads:[~2006-11-11 20:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-06 16:56 [gentoo-amd64] Gnupg doesn't build Mark Haney
2006-11-06 16:55 ` Daniel Gryniewicz
2006-11-06 18:00 ` Christoph Mende
2006-11-06 17:06 ` Mark Haney
2006-11-06 17:24 ` Neil Bothwick
2006-11-07 1:31 ` [gentoo-amd64] coreutils-6.4 - cannot install Mauro Maroni
2006-11-07 1:36 ` [gentoo-amd64] coreutils-6.4 - cannot compile Mauro Maroni
2006-11-07 8:39 ` [gentoo-amd64] " Duncan
2006-11-08 23:25 ` Mauro Maroni
2006-11-09 10:51 ` Duncan
2006-11-11 20:54 ` Mauro Maroni [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=200611111754.20353.mmaroni@fi.uba.ar \
--to=mmaroni@fi.uba.ar \
--cc=gentoo-amd64@lists.gentoo.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