[INFO] Sudden Death galaxy S3 ( Morti Improvvise)

[stefal639]

Ciao Stefal639, (1) I know, eppure è ciò che ho fatto. E dopo update a Jellybean andava pure liscio. Onestamente non sono entrato in download mode prima di trovarlo brikkato ergo non saprei dire se quel custom sia comparso dopo update Kies o dopo "rottura" che ancora non so identificare. (2) Dopo che Samsung mi ha rispedito il telefono dichiarandolo manomesso e fuori garanzia, preso da immane frustrazione, ho fatto delle prove per entrarci con Odin e ripristinarlo (prima no perché non volevo infrangere i termini della garanzia: pensiero inutile, dato l'assurdo esito dell'assistenza). Non è stato comunque possibile fare niente, per errore pit file (e qui si apre un altro problema relativo al partizionamento etc). A tale proposito posso dirti che neppure le procedure deep clean o deep clean2 hanno potuto nulla.

Il mio unico consiglio è prendere il telefono e parlare con l'assistenza samsung stile Mario Magnotta (se non sai chi è youtube ti aiuterà)
Mi spiace...
però il tuo è un problema totalmente differente...mi fa pensare che la tua memoria interna è saltata per qualche problema...insomma come quando saltano i chip di memoria alle chiavette USB o agli SSD.

[attilafe]

Praticamente la questione è questa:
Il bug è nel firmware (il software integrato nel chip di memoria nand) il quale gestisce gli accessi alla scrittura e lettura della memoria e probabilmente non è facilmente aggiornabile (ipotesi)

Quando il sistema operativo è avviato, il kernel (che gestisce l’hardware del telefonino) accede alla memoria nand utilizzando il firmware della stessa ma può anche cambiare i parametri di accesso tramite driver. Facendo questo può mascherare un problema di scrittura/lettura aggirandolo (workaround).

In questo modo il problema è risolto…..ma solo quando il sistema operativo è avviato

Se lo avviate in bootloader o in recovery il kernel non è caricato e quindi il sistema accede alla memoria nand utilizzando il firmware della stessa (bacato) , rovinandola.

Per evitare il problema bisogna integrare il workaround software anche a quelle modalità che non includono il caricamento del kernel (bootloader , recovery , ricarica cell spento)

Tutto ciò non ripara la memoria, se ha raggiunto tipo il 99% della sue massime scritture anche applicando tutte le patch la sua vita è ampiamente ridotta, per cui si romperà comunque , dopo più tempo, ma si romperà

[ferrux61]

Ciao
ma la ROM 4.1.2 inglese XELLA,
visto che aggiorna anche il boot,
non sembrerebbe fare la stessa cosa del kernel di Andrei di XDA ?

In questo caso, se è vero, dovrebbe mettere anche al riparo dal brick in fast di cold boot, o no ?

Fx

[attilafe]

Ciao
ma la ROM 4.1.2 inglese XELLA,
visto che aggiorna anche il boot,
non sembrerebbe fare la stessa cosa del kernel di Andrei di XDA ?

In questo caso, se è vero, dovrebbe mettere anche al riparo dal brick in fast di cold boot, o no ?

Fx

la rom XELLA aggiorna sia i kernel che il bootloader, e probabilmente anche la recovery originale.

Non evita il brik...... corregge i parametri sbagliati che fanno degradare prematuramente la memoria nand.

Se la memoria si è usurata parecchio lavorando con parametri incorretti (prima dell' aggiornamento XELLA)..... prima o poi arriverà alla fine della sua vita anche con un utilizzo corretto.

ipotesi:

La memoria nasce x durare 10 anni di utilizzo normale
Per colpa del bug ha fatto scritture per l' equivalente di 9 anni in solo 6 mesi di vita
Con il software XLLA le rimane 1 anno di vita....poi morirà

Ripeto è solo un ipotesi su dati inventati.....non so quanto dura una nand normalmente e quanto il problema la danneggi

[AndreaHH90]

la rom XELLA aggiorna sia i kernel che il bootloader, e probabilmente anche la recovery originale.

Non evita il brik...... corregge i parametri sbagliati che fanno degradare prematuramente la memoria nand.

Ma ancora non è ufficiale, è solo una nostra ipotesi!

[dennyjersey]

Ci siamo capiti male...il problema totalmente risolto da lui è il bug dell'exynos.
il problema ha cui ha messo una toppa è per l'SDS, se però tale morte avviene con cell spento perchè non si riesce a caricare il kernel, nisba

PS: nulla toglie allo sviluppatore, io uso il suo kernel da tempo...l'ho abbandonato solo temporaneamente per il siyah.
Non ho mai detto che sia un cazzaro, lo dicevo a chi pensava che tale problema fosse totalmente risolto

Bene, l'importante è capirsi!

Praticamente la questione è questa:
Il bug è nel firmware (il software integrato nel chip di memoria nand) il quale gestisce gli accessi alla scrittura e lettura della memoria e probabilmente non è facilmente aggiornabile (ipotesi)

Quando il sistema operativo è avviato, il kernel (che gestisce l’hardware del telefonino) accede alla memoria nand utilizzando il firmware della stessa ma può anche cambiare i parametri di accesso tramite driver. Facendo questo può mascherare un problema di scrittura/lettura aggirandolo (workaround).

In questo modo il problema è risolto…..ma solo quando il sistema operativo è avviato

Se lo avviate in bootloader o in recovery il kernel non è caricato e quindi il sistema accede alla memoria nand utilizzando il firmware della stessa (bacato) , rovinandola.

Per evitare il problema bisogna integrare il workaround software anche a quelle modalità che non includono il caricamento del kernel (bootloader , recovery , ricarica cell spento)

Tutto ciò non ripara la memoria, se ha raggiunto tipo il 99% della sue massime scritture anche applicando tutte le patch la sua vita è ampiamente ridotta, per cui si romperà comunque , dopo più tempo, ma si romperà

Questo intervento mi sembra molto plausibile.
Sarebbe utile riuscire a capire se gli S3 tornati dall'assistenza abbiano come costante un chip emmc che abbia subito un aggiornamento del firmware integrato nella nand.

[attilafe]

Ma ancora non è ufficiale, è solo una nostra ipotesi!

Veramente mi sembra che siano stati trovati nel codice del kernel i parametri di correzione....per il bootloader è solo una supposizione in quanto aggiornarlo è alla fine rischioso e se samsung lo fa avrà un motivo parecchio valido.

per la recovery è solo un ipotesi mia

[ferrux61]

ciao
se caricando la app EMMC check dà come esoto chip: sane
è necessario caricare XELLA ?

Non ho ancora capito se mi conviene passare a XELLA visto che sto usando la ufficiale 4.1.2 XELL4 del mio gestore TRE, che consusione :-/

Grazie.
Fx

[attilafe]

ciao
se caricando la app EMMC check dà come esoto chip: sane
è necessario caricare XELLA ?

Non ho ancora capito se mi conviene passare a XELLA visto che sto usando la ufficiale 4.1.2 XELL4 del mio gestore TRE, che consusione :-/

Grazie.


Fx

EMMC check non nasce x rilevare questo difetto ma per uno dell' s2 mi sembra

A noi serve solo a sapere il tipo e la data di produzione della memoria x fare statistica.

[arker]

ciao
se caricando la app EMMC check dà come esoto chip: sane
è necessario caricare XELLA ?

Brick Bug? NO. Sane chip in eMMC check non ha nulla a che vedere con Galaxy S3 e con le sue morti improvvise! E' un altro problema (Superbrick), che riguarda l'S2.

Se ti appare

eMMC chip
Type: VTU00M
...
FwRev: 0xf1

allora il firmware della memoria è affetto dal problema della morte improvvisa e prima o poi il tuo S3 morirà.
Basta flashare il kernel Perseus 31.2, non serve passare al firmware XELLA.