DOMANDA Dov'è il progresso tecnologico se si usa ancora MemTest?

Pubblicità
Per esperienza, di pc guasti ce ne sono pasasti a migliaia sotto le mani. Al tempo degli HDD, la principale causa di malfunzionamento era proprio il guasto del HDD. Con gli SSD, tolte cinesate da schifo e Kingston*, il problema del guasto dello storage ormai è molto limitato. L'altro componente che si gausta spesso è l'alimentatore, seguito dalla scheda madre.
RAM guaste? Forse 4 banchi in 15 anni...
 
Per esperienza, di pc guasti ce ne sono pasasti a migliaia sotto le mani. Al tempo degli HDD, la principale causa di malfunzionamento era proprio il guasto del HDD. Con gli SSD, tolte cinesate da schifo e Kingston*, il problema del guasto dello storage ormai è molto limitato. L'altro componente che si gausta spesso è l'alimentatore, seguito dalla scheda madre.
RAM guaste? Forse 4 banchi in 15 anni...
Questo mi preoccupa, gli ssd che ho sono della kingston.
 
Se sono degli A400, cambiali quanto prima.
Se sono altri modelli, c'è da vedere.
Io non mi fido di Kingston, ma sembra che gli attuali NVME Kingston vadano bene
 
Ho visto alcuni test di entrambi gli sdd Kinsgton da 120gb ciascuno, in rapporto al taglio da 250gb del Crucial.
Il crucial è più veloce dell'84% rapportato all'SV300 e del 54% all'SUV400.
Mi aspettavo un risultato a favore del Crucial, ma non di così tanto.
Mi ricorderò di questa marca, grazie per il consiglio.
 
Senza entrare nello specifico, abbiamo seguito un caso di un cliente (si parla di grandi macchine), un collega ed io, a cui crashava una macchina ogni due per tre. Abbiamo analizzato il primo crash dump, c'era un problema con un puntatore nullo che riguardava una certa area della memoria; poi un secondo crash, qui puntatore che aveva a che fare con la parte delle irq (interrupts) e così via altri a seguire...

Alla fine della fiera abbiamo totalizzato N vmcore da guardare (con N > 7) dove il 60% mostrava più o meno un pattern, erano simili, e altri erano proprio in zone diverse (ie. interrupts, boot, task_struct, stack di un task_struct, etc).

Ci siamo resi conto che tutti gli indirizzi corrotti (eg. in cui un puntatore faceva riferimento a zone della memoria non accessibili, troppo alte) erano bene o male in un range molto ristretto di indirizzi fisici; cioè, l'indirizzo di memoria che è virtuale, tradotto in fisico, era più o meno nella stessa zona (forse era anche la stessa pagina, non mi ricordo, ma era comunque adiacente).

Abbiamo concluso fosse un problema HW. Hanno testato la RAM ed hanno trovato un modulo danneggiato; poi hanno proseguito a testare l'hw ed hanno trovato una delle cache di una delle CPU con problemi, sino a riscontrarne altri ancora dopo giorni (e altri crash dump, dicendoci "ok, tutto risolto ma crasha ancora").

Questo per dire che è un'area complessa, non c'è solo una cosa che può andare male, non tutti gli errori si riescono a correggere; ogni tanto si vedono single-bit error o parity error che causano crash, anche. Mi è anche capitato di vedere bit-flip a volte, causati da problemi HW... e non sempre vengono poi trovati immediatamente.

Non so poi che usano i vari tecnci HW, ma presumo utilizzino direttamente la strumentazione collegata all'hw per beccare certe cose.
 
Senza entrare nello specifico, abbiamo seguito un caso di un cliente (si parla di grandi macchine), un collega ed io, a cui crashava una macchina ogni due per tre. Abbiamo analizzato il primo crash dump, c'era un problema con un puntatore nullo che riguardava una certa area della memoria; poi un secondo crash, qui puntatore che aveva a che fare con la parte delle irq (interrupts) e così via altri a seguire...

Alla fine della fiera abbiamo totalizzato N vmcore da guardare (con N > 7) dove il 60% mostrava più o meno un pattern, erano simili, e altri erano proprio in zone diverse (ie. interrupts, boot, task_struct, stack di un task_struct, etc).

Ci siamo resi conto che tutti gli indirizzi corrotti (eg. in cui un puntatore faceva riferimento a zone della memoria non accessibili, troppo alte) erano bene o male in un range molto ristretto di indirizzi fisici; cioè, l'indirizzo di memoria che è virtuale, tradotto in fisico, era più o meno nella stessa zona (forse era anche la stessa pagina, non mi ricordo, ma era comunque adiacente).

Abbiamo concluso fosse un problema HW. Hanno testato la RAM ed hanno trovato un modulo danneggiato; poi hanno proseguito a testare l'hw ed hanno trovato una delle cache di una delle CPU con problemi, sino a riscontrarne altri ancora dopo giorni (e altri crash dump, dicendoci "ok, tutto risolto ma crasha ancora").

Questo per dire che è un'area complessa, non c'è solo una cosa che può andare male, non tutti gli errori si riescono a correggere; ogni tanto si vedono single-bit error o parity error che causano crash, anche. Mi è anche capitato di vedere bit-flip a volte, causati da problemi HW... e non sempre vengono poi trovati immediatamente.

Non so poi che usano i vari tecnci HW, ma presumo utilizzino direttamente la strumentazione collegata all'hw per beccare certe cose.
Ho alcune domande:
- la prova sulle ram è stata fatta sempre con MemTest o con altro?
- cosa può causare problemi alla cache della cpu?
- è utile avere un gruppo di continuità in modo da evitare che sbalzi di tensione o interruzioni possano danneggiare l'hardware dato che sono componenti delicati?
 
Senza entrare nello specifico, abbiamo seguito un caso di un cliente (si parla di grandi macchine), un collega ed io, a cui crashava una macchina ogni due per tre. Abbiamo analizzato il primo crash dump, c'era un problema con un puntatore nullo che riguardava una certa area della memoria; poi un secondo crash, qui puntatore che aveva a che fare con la parte delle irq (interrupts) e così via altri a seguire...

Alla fine della fiera abbiamo totalizzato N vmcore da guardare (con N > 7) dove il 60% mostrava più o meno un pattern, erano simili, e altri erano proprio in zone diverse (ie. interrupts, boot, task_struct, stack di un task_struct, etc).

Ci siamo resi conto che tutti gli indirizzi corrotti (eg. in cui un puntatore faceva riferimento a zone della memoria non accessibili, troppo alte) erano bene o male in un range molto ristretto di indirizzi fisici; cioè, l'indirizzo di memoria che è virtuale, tradotto in fisico, era più o meno nella stessa zona (forse era anche la stessa pagina, non mi ricordo, ma era comunque adiacente).

Abbiamo concluso fosse un problema HW. Hanno testato la RAM ed hanno trovato un modulo danneggiato; poi hanno proseguito a testare l'hw ed hanno trovato una delle cache di una delle CPU con problemi, sino a riscontrarne altri ancora dopo giorni (e altri crash dump, dicendoci "ok, tutto risolto ma crasha ancora").

Questo per dire che è un'area complessa, non c'è solo una cosa che può andare male, non tutti gli errori si riescono a correggere; ogni tanto si vedono single-bit error o parity error che causano crash, anche. Mi è anche capitato di vedere bit-flip a volte, causati da problemi HW... e non sempre vengono poi trovati immediatamente.

Non so poi che usano i vari tecnci HW, ma presumo utilizzino direttamente la strumentazione collegata all'hw per beccare certe cose.
Non ci ho capito NIENTE ma complimenti per il lavoro svolto!
 
- cosa può causare problemi alla cache della cpu?
Componenti guaste, sulle CPU è raro, ma può accadere

- è utile avere un gruppo di continuità in modo da evitare che sbalzi di tensione o interruzioni possano danneggiare l'hardware dato che sono componenti delicati?
Ecco, quello sì, secondo me un buon UPS sarebbe sempre bene averlo, su apparati delicati è OBBLIGATORIO (server, apparati di rete, ecc), su pc client non è indispensabile ma di certo male non fa
 
Componenti guaste, sulle CPU è raro, ma può accadere


Ecco, quello sì, secondo me un buon UPS sarebbe sempre bene averlo, su apparati delicati è OBBLIGATORIO (server, apparati di rete, ecc), su pc client non è indispensabile ma di certo male non fa
Allora ho fatto bene anni fa a comprarne uno dell'Apc, un modello più che sufficiente per il pc di casa.
 
Pubblicità
Pubblicità
Indietro
Top