From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Gizuq-0006NB-9P for garchives@archives.gentoo.org; Sat, 11 Nov 2006 20:57:28 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.8) with SMTP id kABKsjh1011160; Sat, 11 Nov 2006 20:54:45 GMT Received: from smtp-02.arnet.com.ar (smtp-02.arnet.com.ar [200.45.191.22]) by robin.gentoo.org (8.13.8/8.13.8) with SMTP id kABKsgLG027869 for ; Sat, 11 Nov 2006 20:54:44 GMT Received: (qmail 1998 invoked from network); 11 Nov 2006 15:43:50 -0000 Received: from unknown (HELO ?10.0.0.200?) (201.253.214.36) by smtp-02.arnet.com.ar with SMTP; 11 Nov 2006 15:43:50 -0000 From: Mauro Maroni 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 User-Agent: KMail/1.9.1 References: <454F6945.1090704@ercbroadband.org> <200611082025.25462.mmaroni@fi.uba.ar> In-Reply-To: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611111754.20353.mmaroni@fi.uba.ar> X-Archives-Salt: 7e64eae8-a179-4132-86ca-cd8532af1f78 X-Archives-Hash: 0c05cbf9419b20e973ca79fd4eab7890 On Thursday 09 November 2006 07:51, Duncan wrote: > Mauro Maroni 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