public inbox for gentoo-amd64@lists.gentoo.org
 help / color / mirror / Atom feed
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



      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