14-08-16, 05:52 AM
[size=0.7em]Que es la MUERTE SUBITA y por que ocurre [/size]
[size=0.7em]¿Que es lo que ocurre ? [/size]
[size=0.7em]El error estaria en la RAM, que es la MEMORIA que se usa para instalar el Sistema Operativo y como SD Interna. [/size]
[size=0.7em]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 lasí el bootloader, provocando que el equipo no encienda. [/size]
[size=0.7em]En resumen (aunque no ocurre lasí 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. [/size]
[size=0.7em]¿Podemos encontrar algún patrón que describa el problema? [/size]
[size=0.7em]Diría que SI (aunque no puedo confirmarlo).[/size]
[size=0.7em]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. [/size]
[size=0.7em]En el caso de los samsung ¿Debería no fallar con el parche de Samsung? [/size]
[size=0.7em]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. [/size]
[size=0.7em]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. [/size]
[size=0.7em]¿Qué modelos fallan? [/size]
[size=0.7em]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. [/size]
[size=0.7em]Confirmaciones: [/size]
[size=0.7em]* Los CHIPS DEFECTUOSOS son los que tienen fecha de fabricacion 2012.04.13 [/size]
[size=0.7em]* Esto puede significar que si hay chips VTU00M 0xf1 que no tienen ese firmware están sanos [/size]
[size=0.7em]* El parche de Samsung NO repara el Chip (porque no se puede), pero evita que el equipo quede inservible. [/size]
[size=0.7em]* El problema se dio aparentemente en 1 sola partida de Chips (fecha 2012.04.13), los demas estan bien. [/size]
[size=0.7em]* El parche de Ariza (parche de MODEM) no modifica el Kernel, por tanto, no entraria enconflicto con el parche de Samsung (parche de Kernel). [/size]
[size=0.7em]* Los Kernels Modificados [/size]
[size=0.7em]como Perseus o Syah, ya tienen aplicadas las correcciones de Samsung y por lo tanto son seguros. [/size]
[size=0.7em]¿ Como saber exactamente cual es la fecha de Fabricacion de nuestro SIII? [/size]
[size=0.7em]Muchos hemos utilizado eMMC Brickbug, descargada desde el PlayStore, pero en realidad no podemos asegurar que la informacion que devuelve sea veraz y efectiva. Los Desarrolladores de Syah Kernel han incluido un comando que nos permitira verificar con exactitud si nuestro SIII esta en peligro de MUERTE SUBITA o no. [/size]
[size=0.7em]1- Lo primero que deben hacer es descargar este Kernel modificado Syah v1.8.7 [/size]
[size=0.7em]2- Luego lo flashean por CWM, deben ser root y tener instalado un Recovery Avanzado. [/size]
[size=0.7em]- Como siempre flashear un Kernel Modificado supone riesgos, asi que haganlobajo su propia responsabilidad -. [/size]
[size=0.7em]3- Una vez reiniciado el equipo descargan del PlayStore "android terminal emulator", que es una consola para ingresar comandos como se hacia en el viejo Microsoft "D.O.S.". [/size]
[size=0.7em]4- Abren Terminal Emulator y luego ingresan el siguiente comando: [/size]
[size=0.7em]cat /sys/class/block/mmcblk0/device/movi_ops ....... y le dan ENTER para que se ejecute ......[/size]
[size=0.7em]5- Si les devuelve valor "0" su Chip esta libre de fallos / Si les devuelve valor "2" el Chip pertenece a la [/size]
[size=0.7em]fecha de fabricacion con la falla registrada, alias "MUERTE SUBITA". [/size]
Cree en ti y en lo que haces, porque cuando crees...todo es posible.
Codigos de liberacion y algo mas.
Codigos de liberacion y algo mas.
