From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 1C3AC1397F2 for ; Fri, 21 Aug 2015 23:39:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 98543E081C; Fri, 21 Aug 2015 23:39:41 +0000 (UTC) Received: from mail-yk0-f179.google.com (mail-yk0-f179.google.com [209.85.160.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 602BBE07FA for ; Fri, 21 Aug 2015 23:39:40 +0000 (UTC) Received: by ykbi184 with SMTP id i184so85983231ykb.2 for ; Fri, 21 Aug 2015 16:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=wWHc76HJ0RQE0AJa/ybKgOBaXJdhRKeZfLyWp9NFR7k=; b=CCPZFYg5KPIkjfueQpLRS0NrtWqRVrnBA9yI00w05uKfe/8mLpeu5nfM1AdXSlcjdB N1LJaA7oht/rdwv+6EjX/4toEq6VOPMYrlTnhBWeeBfAWImOZFdNxplomfc2IeTcsFY/ ki2GXtCyKy2+LlUu7kCzhnUrUkv0BJvi6y7VDqcjBT6EwqAjwHDoO3RnSGf5sQsUg+5H YqBBQ8A7Z6DSiVcB1YDyDy/sTRJb4l/HFEz0SEX09GYmA11W2CSCKsIpZIaouaB2B7tr fyrg5Xcb/vI6i+VN2uRZ+8bNnXjPvP292It2wv66y29856FEU0cdPmqDmBIH8vWkYbnC yJIA== X-Received: by 10.129.128.197 with SMTP id q188mr15660182ywf.121.1440200379455; Fri, 21 Aug 2015 16:39:39 -0700 (PDT) Received: from [192.168.2.5] (adsl-65-0-123-251.jan.bellsouth.net. [65.0.123.251]) by smtp.gmail.com with ESMTPSA id x8sm9055259ywa.41.2015.08.21.16.39.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Aug 2015 16:39:38 -0700 (PDT) Message-ID: <55D7B6B9.8010609@gmail.com> Date: Fri, 21 Aug 2015 18:39:37 -0500 From: Dale User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0 SeaMonkey/2.33.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: Epic list of total FAIL. References: <55D637E0.3080409@verizon.net> <55D65554.1010608@verizon.net> <55D67CD2.3030400@wraeth.id.au> <55D683C1.7020100@verizon.net> <55D68FCF.6020105@wraeth.id.au> <55D6C0AD.8060501@gmail.com> <55D73D00.3080308@verizon.net> In-Reply-To: <55D73D00.3080308@verizon.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 7934ea70-cc99-46c1-84b9-e953190864c7 X-Archives-Hash: e940a0f77677206bbc977b1a57ef7368 Alan Grimes wrote: > Grant Edwards wrote: >> On 2015-08-21, Alan McKinnon wrote: >> >>> Earlier I saw segfaults in gcc, and another poster pointed it out. >>> >>> When gcc segfaults, it is always suspicious mostly because the compil= er >>> is an app where we know the devs take extraordinary measures to preve= nt it. >>> >>> The most common cause is faulty hardware (most often memory) as gcc >>> tends to use all of it in ways no other app does. The usual procedure= >>> at this point is to run memtest for an extended period - say 48 >>> hours, or even 72 for an older slow machine. >> That is definitely good advice. I've run into this situation several >> times. A machine had bad RAM that didn't seem to cause any problems >> under "normal" operation. But, when trying to compile something large= >> like gcc, I would see non-repeatable segfaults (it wouldn't always >> segfault at the exact same point). In those cases, I could often run >> memtest for several passes and not see an error. But, _eventually_ >> ramtest would catch it. Run memtest for a few days. Really. > Yeah, I know there's a single bit error out at the end of RAM that will= > appear on the third or fourth pass... > > I have already RMA'd half of the ram in this machine because it was > giving a whole fist-full of errors across two sticks... I run the rusty= > old bus on the CPU ( SIX CORES!!!!) a bit harder than it was intended > in order to keep up with the new junk. My previous machine had ECC. =3D= ( > > I was advised to just jack the voltage a little bit and live with it. I= > guess I'd better run more tests and see what the situation is.... > > It just doesn't seem reasonable to demand that every bit in a 32 > gigabyte memory bank be absolutely perfect.... > You know those multi terabyte hard drives they make, every bit of those platters that are actively in use must work perfectly. If just one thing, just one tiny bit, is not working correctly, you get bad data.=20 With computers, one bit of bad data means something doesn't work be it hard drives or memory or even the CPU. You may can live with it on widoze but not Linux. Linus maximizes the use of memory more so than windoze. I have 16Gbs of ram here. Even if I don't compile anything, eventually all my memory will be used by cache if nothing else. Once that cache hits a bad spot, there is trouble. Might I also add, whoever told you to live with it, I hope they don't work on airplanes and I wouldn't take advice from them to much on puter stuff in the future.=20 Just my $0.02 worth. Dale :-) :-)=20