Muerte súbita Samsung Galaxy S3 que es y como repararlo

¿Que es lo que ocurre ? 

El error estaria en la RAM, que es la MEMORIA que se usa para instalar el Sistema Operativo y como SD Interna. 

Lo que ocurre es que el bit que controla el wear lev cuando trata de escribir al final de la tarjeta, se pasa, devolviendo una dirección de memoria que no corresponde (por desbordamiento), y escribiendo así el bootloader, provocando que el equipo no encienda. 

En resumen (aunque no ocurre así exactamente) el wear, que apunta a donde debe escribir, se le va la mano y se pone a escribir en direcciones que no existen, estas direcciones provocan que el inicio de la eMMC sea sobreescrito. 

¿Podemos encontrar algún patrón que describa el problema? 

Diría que SI (aunque no puedo confirmarlo). El patrón será teléfonos que contienen muchos datos en su memoria, y que son reescritos habitualmente. Es decir, tienes la memoria casi llena, y cambias los datos de ella de vez en cuando. Por ejemplo, la tienes a tope de música y cambias canciones por otras nuevas porque no te entran. 

También entraría en este patrón la gente que no tiene la memoria muy llena, pero si la cambia a menudo. (Instala muchas roms, copia muchas cosas a la memoria interna desde el PC...) 

Esto ocurre cuando el wear leveling llega al final de la eMMC, en ciertas ocasiones y tras un numero de ciclos de escrituras, se salta el final de la tarjeta, y bueno, los que lo hayan estudiado, ya saben que un bit que no exista en la memoria supone escribir en una parte que no quieres. 

¿Debería no fallar con el parche de Samsung? 

Si, debería no fallar, sin embargo el parche contiene una singularidad. Si ocurriera el bug durante el funcionamiento del dispositivo (recordemos que las probabilidades de que ocurra son muy pocas) el kernel entraría en un loop infinito bloqueando el teléfono. Esto es una medida de prevención (a mi parecer). 

Asi que recuerda, que si se te ha quedado el teléfono bloqueado durante el arranque con alguna versión parcheada, y no sabes por qué, quizás sea porque se acaba de producir el bug y el kérnel ha impedido que destroce el teléfono. La probabilidad de que esto ocurra es tan baja que probablemente tu bloqueo sea motivo de otra cosa. Si esto ocurriera, tras un reinicio volvería a funcionar. 

De hecho, estadisticamente hablando, esto ocurriría en 1 de cada 20 millones de encendidos, acercándose la probabilidad a 1/128 cada vez que se copian datos a la eMMC en todos los bloques tras unas 10000 lecturas de cada uno de ellos. 

La probabilidad de que ocurriese en uno de cada 128 reinicios (la más desfavorable) sería tras escribir 156 Teras de información en el chip. Si copiaran en la memoria 10GB al día (cosa que nadie hace) el teléfono quedaría inútil en 43 años con el BUG. Esto indicaría que la memoria moriría antes por uso que el teléfono por el bug con el fix apilcado. No tomen al pie de la letra esta estadística, por favor. 

¿Qué modelos fallan? 

Curiosamente, según nos indica el kernel, no fallan todos los modelos de VTU00M 0xf1, si no sólo los que tienen el firmware fecha 13/04/2012. Los de otras fechas (si existiesen) no fallarían. 

Solucion :

Confirmaciones: 

* Los CHIPS DEFECTUOSOS son los que tienen fecha de fabricacion 2012.04.13 

* Esto puede significar que si hay chips VTU00M 0xf1 que no tienen ese firmware están sanos 

* El parche de Samsung NO repara el Chip (porque no se puede), pero evita que el equipo quede inservible. 

* El problema se dio aparentemente en 1 sola partida de Chips (fecha 2012.04.13), los demas estan bien. 

* El parche de Ariza (parche de MODEM) no modifica el Kernel, por tanto, no entraria enconflicto con el parche de Samsung (parche de Kernel). 

* Los Kernels Modificados como Perseus o Syah, ya tienen aplicadas las correcciones de Samsung y por lo tanto son seguros. 





QUIZA TE INTERESE : 

Cuatro formas de rootear Cualquier Móvil con Android Sin PC y en 20 segundos 2017

fuente : taringa