You are not logged in.
After new installation my system started behaving really weird and I found out that one of my RAM sticks is faulty. I was using my PC the entire day with no problems until that, so it must have happened during the installation process. Kinda strange. Anyways, did it again with the one stick left and all is good so far, so maybe just a coincidence.
Last edited by Worstarchuser (Today 13:39:02)
Offline
It is hard to comment on this, without knowing what “killed” and “faulty” means. But, generally speaking, neither Arch nor any other operating system could hurt RAM.
Offline
If you want to know whether the DIMM is "faulty" see https://wiki.archlinux.org/title/Stress … Memtest86+ but as mpan pointed out: any OS would be an indicator, not the cause and RAM typically doesn't break from one minute to another lest a non-ignorable incident ("so, I left my notebook on the oven for 5 minutes and now it no longer boots => spaghetti must be bad for computers")
Offline
It is hard to comment on this, without knowing what “killed” and “faulty” means. But, generally speaking, neither Arch nor any other operating system could hurt RAM.
Everyone knows what it means... I did memtest which resulted in errors. It is fucked, useless, out of commission. And you never know what can or cannot destroy a piece of HW.
Offline
* voltage
* heat (these two are also called "XMP")
* you're overclocking it
* you're pairing incompatible DIMMs
* market pressure leading to sub-par DIMMs being sold off
* time
* radiation
* god hates you
* pretty much everything else
* still not software I'm afraid
Offline
* voltage
* heat (these two are also called "XMP")
* you're overclocking it
* you're pairing incompatible DIMMs
* market pressure leading to sub-par DIMMs being sold off
* time
* radiation
* god hates you
* pretty much everything else
* still not software I'm afraid
https://en.wikipedia.org/wiki/Killer_poke
Though that probably didn't happen here in this case. ![]()
Offline
Everyone knows what it means...
No. Others do not share state of your mind and don’t see what you seen. Unless you tell them. “Killed” and “faulty” give zero technical insight. If you expect any reasonable evaluation of the situation, one has to know what exactly were and are the symptoms.
I did memtest which resulted in errors.
Great, that is already some information. You did not provide it earlier. This still doesn’t tell us what made you run memtest in the first place.
And you never know what can or cannot destroy a piece of HW.
While writing the title of this thread you seemed to have an opposite belief: you susggested system installation did it.
But in fact we can know what can and can’t destroy a piece of hardware. In this universe there is only a very tiny subset of things that can. Installation of an operating system is not among them. Even chances for OS installation to make a preëxisting issue evident are low.
Either way… do you have any actual questions? Initially I believed you do, but now I start having doubts.
Offline
Though that probably didn't happen here in this case.
![]()
I was thinking about RAM specifically.
Interestingly it doesn't mention https://man.archlinux.org/man/hdparm.8#security-freeze (though technically the hardware remains undamaged it's a reliable way to effectively brick it)
And of course any old process can brick a raptor lake CPU ![]()
This still doesn’t tell us what made you run memtest in the first place.
If you want to know whether the DIMM is "faulty" see https://wiki.archlinux.org/title/Stress … Memtest86+
"Divine intervention."
Offline
Either way… do you have any actual questions? Initially I believed you do, but now I start having doubts.
I wanted to see if there are more cases or if it was just coincidence.
And my experience was very similar to https://bbs.archlinux.org/viewtopic.php?id=314929. I got Ryzen 5500, MSI B550 A-Pro, 2x8Gb 3600Mhz Patriot
On my previous system I didn't have the "amd-ucore.img" in the boot folder. Possible that that might have done something.
Offline
For genuinely broken RAM (memtest86+) it's coincidence.
Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.
Offline
“amd-ucore.img” or “amd-ucode.img”? I guess the latter and, if yes, it’s just microcode for your processor. Hypothetically, invalid microcode could cause CPU execute code incorrectly and exhibit errors mimicking data corruption. But loading a microcode update is transient: the changes disappear once the processor is reset. So memtest wouldn’t be affected. The bug in microcode would also be announced already.⁽¹⁾
Until there is a reason to think it’s otherwise, it must be taken as a coincidence. No symptoms were described that would make me think otherwise, so I have to stay with this initial guess: a coincidence.
Mind that even if you described symptoms pointing to something else than a coincidence, it would not be an OS installation causing it. Rather the installation either revealing an already existing fault, or triggering a brooding failure.
____
⁽¹⁾ We had a good example with Intel’s update on August 12th.
Last edited by mpan (Yesterday 21:27:20)
Offline