Crash di sistema inaspettati, quasi sempre è colpa della memoria

Secondo le.mie esperienze al primo posto ci sta il sw .

Poi gli hhd , poi le ram e poi tutto il resto.

Quanti dischi rotti in vita mia .... Quante bsod...

gli errori dram sono del tipo "silent", pacifico non comprendi il titolo e il problema

sono i famosi "chissà perché ci sta mettendo più del normale per salvare", "ma perché questo programma non si chiude?", "perché non mi apre più questo file?", "che strano mi ha scaricato un file che non funziona, ma ora che l'ho riscaricato va", "dopo 4 ore che stavo giocando mi è crashato il PC", "chissà perché mi si è riavviato il PC, ieri era acceso" e via dicendo...

La correzione ECC c'è in tutta la catena informatica, dalla cache della CPU, ai dati trasmessi tramite il DMI, a quelli tramite il PCIE e pure la cache dei minicore della VGA (nel settore professionale pure la RAM della VGA)... l'unico dove misteriosamente manca sono la RAM consumer. Abbiamo dotazioni di fino 32GB in dual channel e nessun sistema di salvaguardia dell'integrità dei dati che vi transitano... Alquanto stupido eppure pure facilmente aggirabile come problema (basta 1 chip DRAM in più e grazie al doppio canale si è protetti pure per il multi-bit error oltre che il single-bit error)

http://www.intelligentmemory.com/fi...IM_ECC_DRAM.pdf

Forse ho sbagliato a ricollegate i crash di sistema alle bsod.

Evidentemente si riferivano a eventi occulti.

Poi io parlo della mia esperienza personale , dove va anche detto che le ram sono sempre state di marca buona. ( kingstone , corsair, samsung...)

Ps i file scaricati " male " da internet mi capitano a lavoro.

Ma credevo dipemdesse dalla rete. Dici che sono le.ram? Se così gli faccio un test. ( bsod mai viste su quel pc)

ammetto che quando ho letto decadimento alpha non volevo crederci ed ho cercato qualche fonte per capire come è andata.

Non è che tutti i chip erano affetti da errori dovuti a decadimento alpha eh... solo gli IBM. tra l'altro già nell'81 in IBM avevano tovato package contaminati da Kr85 (che però emette beta e gamma).

per chi è ineterssato ecco la storia del "Hera Problem"

[B]1987-Radioactive contamination of a semiconductor
factory
No IBM SER historical review would be complete without
mentioning the “Hera problem.” During the year 1986,
there was an anomalous increase in LSI memory
problems. Electronics in early 1987 appeared to have
problem rates approaching 20 times higher than predicted.
In contrast, identical LSI memories being manufactured in
Europe showed no anomalous problems. Because of
knowledge of the radioactivity problem with the Intel’ 2107
RAMS [9], it was thought that the LSI package probably
was at fault, since the IBM chips were mounted on similar
ceramic materials. LSI ceramic packages made by IBM
in Europe and in the U.S. were exchanged, but the
European computer modules (with European chips and
U.S. packaging) showed no fails, while the U.S. chips
with European packages still failed at a high rate. This
indicated that the problem was undoubtedly in the USmanufactured
LSI chips. In April 1987, significant design
changes had been made to the memory chip with the most
problems, a 4Kb bipolar RAM. The newer chip had been
given the nickname Hera, and so at an early stage the
incident became known as the “Hera pr~blem.”’~
By June 1987, the problem was very serio~s.’~ A group
was organized to investigate the problem. The first
breakthrough in understanding occurred with the analysis
of “carcasses” from the memory chips (the term carcasses
refers to the chips on an LSI wafer which do not work
correctly, and are not used but saved in case some
problem occurs at a future time). Some of these
carcasses were shown to have significant radioactivity

Six weeks was spent in the manufacturing process
lines, looking for radioactivity, and traces were found
inside various processing units. However, it could not be
determined whether these traces came from the raw
materials used, or whether they were transferred from the
chips themselves, which might have been contaminated
earlier in their processing. Further, it was discovered that
radioactive filaments (containing radioactive thorium) were
commonly used in some evaporators. A detailed analysis
by T. Zabel of some of the “hot” chips revealed that the
radioactive contamination came from a single source:
Po210. This isotope is found in the uranium decay chain,
which contains about twelve different radioactive
species. The surprising fact was that Po210 was the only
contaminant on the LSI chips, and all the other expected
decay-chain elements were missing. Hundreds of chips
were analyzed for radioactivity, and Po210 contamination
was found going back more than a year. Then it was
found that whatever caused the radioactivity problem
disappeared on all wafers started after May 22, 1987.
After this precise date, all new wafers were free of
contamination (Figure lo), except for small amounts which
probably were contaminated by other older chips being
processed by the same equipment. Since it takes about
four months for chips to be manufactured, the pipeline
was still full of “hot” chips in July and August 1987.
Further sweeps of the manufacturing lines showed trace
radioactivity, but the plant was essentially clean. The
contamination had appeared in 1985, increased by more
than 1000 times until May 22, 1987, and then totally
disappeared!

Several months passed, with widespread testing of
manufacturing materials and tools, but no radioactive
contamination was discovered. All memory chips in the
manufacturing lines were spot-screened for radioactivity,
but they were clean. The radioactivity reappeared in the
manufacturing plant in early December 1987, mildly
contaminating several hundred wafers, then disappeared
again. A search of all the materials used in the fabrication
of these chips found no source of the radioactivity. With
further screening, and a lot of luck, a new and unused
bottle of nitric acid was identified by J. Hannah as
radi~active.'~ One surprising aspect of this discovery was
that, of twelve bottles in the single lot of acid, only one

was contaminated. Since all screening of materials
assumed lot-sized homogeneity, this discovery of a single
bad sample in a large lot probably explained why previous
scans of the manufacturing line had been negative. The
unopened bottle of radioactive nitric acid led investigators
back to a supplier's factory, and it was found that the
radioactivity was being injected by a bottle-cleaning
machine for semiconductor-grade acid bottles." This bottle
cleaner used radioactive Po210 material to ionize an air jet
which was used to dislodge electrostatic dust inside the
bottles after washing. The jets were leaking radioactivity

because of a change in the epoxy used to seal the Po210
inside the air jet capsule. Since these jets gave off
infrequent and random bursts of radioactivity, only
a few bottles out of thousands were contaminated.”
Once the contamination was identified and the source
pinpointed to the acid etch bottles, contaminated etch
bottles were replaced with clean bottles and the problem
completely disappeared. All Hera chips from “hot” lots
were recalled from the field and were replaced with clean
Hera chips. [/B]

fonte http://www.pld.ttu.ee/IAF0030/curtis.pdf

Chi non usa del polonio 210 nel suo processo di produzione di acido per circuiti integrati?

Ottimo articolo, complimenti all'autore!!

complimenti bravi
io quando qualche banco fa le bizze metto in forno e ritona a funzionare

condivido, la maggior parte dei crash dipendono dalle ram e spesso i TIMINGS indicati dai produttori per esaltarne le prestazioni sono irreali, o i firmware risultano incompleti dei timings principali, oltre a considerare le limitazioni dei vari chipset da cui dipende la gestione delle memorie e nei BIOS deficitari (che i produttori di schede madri non aggiornano onde generare OBSOLESCENZA PROGRAMMATA).

Le utenze acquistano hardware il cui MARKETING esalta capacità eccellenti ma che per le ragioni citate i dispositivi NON riescono ad esprimere... limitati da hardware di installazione, chipset, software e quant'altro. (su hardware longevo o legacy un sistema operativo come Lbuntu risolve molto sfruttando adeguatamente l'accelerazione hardware (video/audio) nella fruizione multimediale permettendo fluidamente la visione di filmati HD corredati dalle moderne codifiche: esempio atto a dimostrare quanto il software sia importante a sfruttare degnamente l'HARDWARE PAGATO per svolgere le sue funzioni).

se le ecc effettivamente non sono al 100% infallibili, visti i moduli di memeria ed i vari chip, non potrebbero implementare qualcosa di più efficiente quale Checksum o crc per la codifica dell'errore???!! si impatterebbe cosi tanto alle performance??

Con un CRC puoi trovare un errore ma non puoi correggerlo, cosa che invece ECC consente, inoltre il calcolo del checksum è dispendioso, non è fattibile su una RAM

domanda...

Ma nella pratica come faccio ad individuare le aree corrotte della ram in modo da escluderle modificando il registro di sistema? E precisamente...quale voce andrebbe modificata?...sarebbe utile una guida in proposito...

P.S. ma il tgtech??? è morto???