T
trayzor
Dauer-User
- 338
Nein, es betrifft generell ALLE ICS-Kernel. Um genauer zu sein, hat das sogar recht wenig mit dem Kernel zu tun, um nicht zu sagen : gar nichts.Thoddü;3413408 schrieb:Sowie ich das mitbekommen habe, war der Fehler nur beim RC6 des Siyah-Kernels vorhanden, wurde seitdem aber längst gefixt. Wer also einen neueren Kernel hat, dürfte keine Probleme haben.
Kernel, die auf dem Siyah basieren, dürften dann aber natürlich auch betroffen sein, sofern sie auf RC6 basieren.
Gut, das ich noch immer auf Gingerbread fahre
Ich versuche mal das xda-Resumee (Discussion thread for /data EMMC lockup/corruption bug - Page 43 - xda-developers) zu resumieren :
- Das Problem wird durch die Funktion "make_ext4fs()" ausgelöst. Sie gehört NICHT zum Kernel, sondern zu einer externen Bibliothek (Programmbibliothek), die "libext4_utils.a", die beim Kompilieren des Recoverys benutzt wird.
- Diese Funktion wird sowohl bei einem wipe/factory reset als auch beim restoren eines Backups im Recovery-Menü benutzt.
- Dieser Bug tritt erst seit ICS auf, da die Funktion in ihrer Art geändert wurde - in GB hat diese Funktion nicht versucht, die Partition zu formatieren bevor das Dateisystem (EXT4) erstellt wurde, es geht also speziell um die Funktion format(). Unter ICS ist das allerdings der Fall. Dies wiederum kann den eMMC superbrick bug auslösen. Das kann bei einer GB-Basis gar nicht erst passieren, da der Aufruf geblockt wird.
- Der Bug tritt beim Shiften (Bitweiser Operator) auf. Daher ist es mehr oder weniger Zufall, wann der Bug auftritt.
- Das Recovery an sich kann bombensicher gemacht werden, indem man auf eine GB-Basis aufbaut. In dieser ist ja der potentielle Bugauslöser nicht enthalten.
- Jedoch ist dies nicht die einzige Quelle : Bei einem Update- bzw Flashvorgang via Recovery (install update.zip bzw install zip from sd card) wird die update-binary, eine Art Helferapp, aufgerufen (wer sich einen Kernel mal angeschaut hat, der findet das meist unter META-INF/com/google/android/). Bei diesem Flashvorgang wird vom Recovery aus eigentlich nichts gemacht ; das wichtigste übernimmt eben diese Helferapp. Sie ruft unter anderem auch diese Funktion auf, die den Bug auslösen kann. Auch hier gilt : Baut man das edify script (update-binary + updater-script) auf GB-Basis auf, dann ist es auch bombensicher.
1) Stellt sicher, dass euer Recovery auf einer GB-Basis gebaut wurdeSo how do you make sure you are totally safe?
1) make sure you are using a "safe" recovery repacked with the stock ICS kernel. This is a Recovery that was compiled against GB-based libext4_utils.a (ie GB source) This will assure you that wipe data/factory reset and nandroid restores are safe
2) whenever you install a ROM for the first time, verify EITHER
a) the ROM install script is NOT performing any format() calls
b) the ROM install has bundled a GB-based update-binary
2) Wenn ihr eine Rom das erste mal flasht, stellt sicher, dass
a) das edify script keine format()-Methoden aufruft
b) es auf einer GB-Basis gebaut wurde.
Anmerkung : Das ganze ist auf code tracing entstanden, d.h. es lagen zum Zeitpunkt des Posts noch keine RL-Resultate vor. Das ganze klingt aber dahingehend plausibel, als dass der Bug in der Form von einem offiziellen Android Dev letztens schon bestätigt wurde.
@MadMurdoc : Das ist kein hardwareseitiger Fehler. Der besagte Android Dev hat auch schon an einem Fix gearbeitet.