From: Grant <emailgrant@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] gcc fails and then succeeds - definitely a problem?
Date: Thu, 23 Feb 2012 13:11:10 -0800 [thread overview]
Message-ID: <CAN0CFw3=euia5cbFJ93EWbSzVRPqgF=j5MgNaknLw0SEKMWMhw@mail.gmail.com> (raw)
In-Reply-To: <CAN0CFw0or8-+xUc_0F59Zi99uQ=t=D2Hc-6F+veBaneF20F-Qw@mail.gmail.com>
>>> The gcc update just failed to compile on one of my systems with a
>>> segfault, but then succeeded after trying again even though I didn't
>>> change anything. Does that indicate a hardware problem for sure?
>>> Should I run memtester? Any other tests to run? Nothing in dmesg.
>>
>> Not definitively anything; it could have been a race condition.
>>
>> Memtest if you like. prime95 is designed for CPU and memory burning,
>> too, and wouldn't require you to shutdown your system.
>
> Thanks everyone. I ran memtester for a little bit and it came up with
> this before I killed it:
>
> # memtester 14000
> memtester version 4.0.8 (64-bit)
> Copyright (C) 2007 Charles Cazabon.
> Licensed under the GNU General Public License version 2 (only).
>
> pagesize is 4096
> pagesizemask is 0xfffffffffffff000
> want 14000MB (14680064000 bytes)
> got 14000MB (14680064000 bytes), trying mlock ...locked.
> Loop 1:
> Stuck Address : ok
> Random Value : ok
> FAILURE: 0x524e8edb0512f3a7 != 0x524ecedb0512f3a7 at offset 0x04bd5130.
> FAILURE: 0x224c0b76048d37c0 != 0x224c4b76048d37c0 at offset 0x0de17970.
> FAILURE: 0x207dad0b8c3aced0 != 0x207ded0b8c3aced0 at offset 0x0de36970.
> FAILURE: 0x847e610e840fb84e != 0x847e210e840fb84e at offset 0x1dc7922f.
> FAILURE: 0x3f69916b940c7907 != 0x3f69d16b940c7907 at offset 0x1ed37770.
> Compare XOR : FAILURE: 0x13664bb2c7a58ca3 !=
> 0x13668bb2c7a58ca3 at offset 0x04bd5130.
> FAILURE: 0x61bcd9d27eba2967 != 0x61bd19d27eba2967 at offset 0x0686b930.
> FAILURE: 0xe363c84dc71fd0bc != 0xe364084dc71fd0bc at offset 0x0de17970.
> FAILURE: 0xe19569e34ecd67cc != 0xe195a9e34ecd67cc at offset 0x0de36970.
> FAILURE: 0x7b844f40969fc496 != 0x7b848f40969fc496 at offset 0x0de94930.
> FAILURE: 0x45961de646a2514a != 0x4595dde646a2514a at offset 0x1dc7922f.
> FAILURE: 0x67e4594142a19ffa != 0x67e4994142a19ffa at offset 0x1ea14730.
> FAILURE: 0x8341dc6542a103ab != 0x83421c6542a103ab at offset 0x1ecd4730.
> FAILURE: 0x814e43569f1203 != 0x818e43569f1203 at offset 0x1ed37770.
> Compare SUB : FAILURE: 0x1082d4779192eec4 !=
> 0xefbfd4779192eec4 at offset 0x02d10930.
> FAILURE: 0xad2dd70ca745ff5c != 0x8c6ad70ca745ff5c at offset 0x04bd5130.
> FAILURE: 0x189f6452fe165a2c != 0xf7dc6452fe165a2c at offset 0x0686b930.
> FAILURE: 0xc9ac41a7eab20330 != 0xa8e941a7eab20330 at offset 0x0de17970.
> FAILURE: 0x1b9b05b99a41be70 != 0xfad805b99a41be70 at offset 0x0de36970.
> FAILURE: 0x300cb2e02ea06f8 != 0xe23dcb2e02ea06f8 at offset 0x0de94930.
> FAILURE: 0xb29086ae7fdf2d4 != 0xea66086ae7fdf2d4 at offset 0x0e1c5970.
> FAILURE: 0x89126e3b0ccb5288 != 0xa9d56e3b0ccb5288 at offset 0x1dc7922f.
> FAILURE: 0x4d7afcf6378f9248 != 0x2cb7fcf6378f9248 at offset 0x1ea14730.
> FAILURE: 0x5a9034aa259352fc != 0x39cd34aa259352fc at offset 0x1ecd4730.
> FAILURE: 0x7b1c0d3184539edc != 0x5a590d3184539edc at offset 0x1ed37770.
> Compare MUL : FAILURE: 0x00000000 != 0x00000001 at offset 0x0686b930.
> FAILURE: 0x00000000 != 0x00000001 at offset 0x0de36970.
> Compare DIV : Compare OR : ok
> Compare AND : ok
> Sequential Increment: ok
> Solid Bits : testing 29
>
> Now I've emerged gimps and I'm running the mprime "Blend" stress test
> so we'll see what that turns up.
>
> - Grant
mprime ran for about 1.5 hours until it found this:
[Work thread Feb 23 13:04] FATAL ERROR: Rounding was 0.5, expected less than 0.4
[Work thread Feb 23 13:04] Hardware failure detected, consult stress.txt file.
[Work thread Feb 23 13:04] Torture Test completed 85 tests in 1 hour,
33 minutes - 1 errors, 0 warnings.
[Work thread Feb 23 13:04] Worker stopped.
[Main thread Feb 23 13:04] Execution halted.
I have a 1200 watt Corsair power supply and my temps are very low even
during the stress test so I'm thinking bad (Corsair) RAM. I should
remove modules one at a time and re-test to narrow it down?
- Grant
next prev parent reply other threads:[~2012-02-23 21:12 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-23 19:17 [gentoo-user] gcc fails and then succeeds - definitely a problem? Grant
2012-02-23 19:23 ` Michael Mol
2012-02-23 19:40 ` Grant
2012-02-23 21:11 ` Grant [this message]
2012-02-23 21:18 ` Mark Knecht
2012-02-23 21:27 ` Alex Schuster
2012-02-23 19:25 ` [gentoo-user] " Heorhi Valakhanovich
2012-02-23 19:28 ` [gentoo-user] " Mark Knecht
2012-02-23 19:36 ` Michael Mol
2012-02-23 19:46 ` Mark Knecht
2012-02-23 21:37 ` Alan McKinnon
2012-02-23 19:39 ` Alan McKinnon
2012-02-23 19:47 ` Grant
2012-02-23 20:38 ` Neil Bothwick
2012-02-23 21:00 ` Grant
2012-02-23 22:05 ` Michael Mol
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='CAN0CFw3=euia5cbFJ93EWbSzVRPqgF=j5MgNaknLw0SEKMWMhw@mail.gmail.com' \
--to=emailgrant@gmail.com \
--cc=gentoo-user@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