From: Dale <rdalek1967@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".
Date: Wed, 4 Sep 2024 19:11:13 -0500 [thread overview]
Message-ID: <59c36200-9865-066e-a66a-3f3aecd25fe6@gmail.com> (raw)
In-Reply-To: <2201993.Mh6RI2rZIc@rogueboard>
Michael wrote:
> On Wednesday 4 September 2024 23:07:17 BST Grant Edwards wrote:
>> On 2024-09-04, Dale <rdalek1967@gmail.com> wrote:
>>> At one point, I looked for a set of four sticks of the memory. I
>>> couldn't find any. They only come in sets of two. I read somewhere
>>> that the mobo expects each pair to be matched.
>> Yep, that's definitely how it was supposed to work. I fully expected
>> my two (identically spec'ed) sets of two work. All the documentation I
>> could find said it should. It just didn't. :/
>>
>> --
>> Grant
> Often you have to dial down latency and/or increase voltage when you add more
> RAM modules. It is a disappointment when faster memory has to be slowed down
> because those extra two sticks you bought on ebay at a good price, are of a
> slightly lower spec.
>
> Some MoBos are more tolerant than others. I have had systems which failed to
> work when the additional RAM modules were not part of a matching kit. I've
> had others which would work no matter what you threw at them. High
> performance MoBos which have highly strung specs, tend to require lowering
> frequency/increasing latency when you add more RAM.
>
> Regarding Dale's question, which has already been answered - yes, anything the
> bad memory has touched is suspect of corruption. Without ECC RAM a dodgy
> module can cause a lot of damage before it is discovered. This is why I
> *always* run memtest86+ overnight whenever I get a new system, or add new RAM.
> I've only had one fail over the years, but I'd better be safe than sorry. ;-)
When I built this rig, I first booted the Gentoo Live boot image and
just played around a bit. Mostly to let the CPU grease settle in a
bit. Then I ran memtest through a whole test until it said it passed.
Only then did I start working on the install. The rig has ran without
issue until I noticed gkrellm temps were stuck. They wasn't updating as
temps change. So, I closed gkrellm but then it wouldn't open again.
Ran it in a console and saw the error about missing module or
something. Then I tried to figure out that problem which lead to seg
fault errors. Well, that lead to the thread and the discovery of a bad
memory stick. I check gkrellm often so it was most likely less than a
day. Could have been only hours. Knowing I check gkrellm often, it was
likely only a matter of a couple hours or so. The only reason it might
have went longer, the CPU was mostly idle. I watch more often when the
CPU is busy, updates etc.
I just hope I can put in all four sticks and it work once the bad set is
replaced. I miss having 64GBs of memory already.
Oh, QB is redoing a lot of files. It seems it picked up on some . . .
issues. :/
Dale
:-) :-)
next prev parent reply other threads:[~2024-09-05 0:11 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-03 23:28 [gentoo-user] Package compile failures with "internal compiler error: Segmentation fault" Dale
2024-09-04 0:12 ` [gentoo-user] " Grant Edwards
2024-09-04 0:39 ` Dale
2024-09-04 4:16 ` corbin bird
2024-09-06 20:15 ` Dale
2024-09-06 23:17 ` Michael
2024-09-07 3:02 ` Dale
2024-09-07 22:12 ` Wols Lists
2024-09-08 1:59 ` Dale
2024-09-08 13:32 ` Michael
2024-09-08 9:15 ` Michael
2024-09-08 20:19 ` Wol
2024-09-04 7:53 ` Raffaele Belardi
2024-09-04 4:26 ` [gentoo-user] " Eli Schwartz
2024-09-04 10:48 ` [gentoo-user] " Dale
2024-09-04 11:05 ` Frank Steinmetzger
2024-09-04 11:21 ` Dale
2024-09-04 15:57 ` Peter Humphrey
2024-09-04 19:09 ` Grant Edwards
2024-09-04 21:08 ` Frank Steinmetzger
2024-09-04 21:22 ` Grant Edwards
2024-09-04 21:53 ` Dale
2024-09-04 22:07 ` Grant Edwards
2024-09-04 22:14 ` Dale
2024-09-04 22:38 ` Michael
2024-09-05 0:11 ` Dale [this message]
2024-09-05 8:05 ` Michael
2024-09-05 8:36 ` Dale
2024-09-05 8:42 ` Michael
2024-09-05 10:53 ` Dale
2024-09-05 11:08 ` Michael
2024-09-05 11:30 ` Dale
2024-09-05 18:55 ` Frank Steinmetzger
2024-09-05 22:06 ` Michael
2024-09-06 0:43 ` Dale
2024-09-06 12:21 ` Michael
2024-09-06 21:41 ` Frank Steinmetzger
2024-09-07 9:37 ` Michael
2024-09-07 16:28 ` Frank Steinmetzger
2024-09-07 17:08 ` Mark Knecht
2024-09-14 19:46 ` Dale
2024-09-15 22:29 ` Frank Steinmetzger
2024-09-16 10:24 ` Dale
2024-09-07 22:48 ` Wols Lists
2024-09-08 9:37 ` Michael
2024-09-05 9:08 ` Frank Steinmetzger
2024-09-05 9:36 ` Michael
2024-09-05 10:01 ` Frank Steinmetzger
2024-09-05 10:59 ` Dale
2024-09-04 14:21 ` Grant Edwards
2024-09-04 11:37 ` Dale
2024-09-04 14:23 ` Grant Edwards
2024-09-04 15:58 ` Peter Humphrey
2024-09-04 19:28 ` Dale
2024-09-25 20:41 ` Dale
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=59c36200-9865-066e-a66a-3f3aecd25fe6@gmail.com \
--to=rdalek1967@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