You are not logged in.
Pages: 1
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.
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
Pages: 1