Der Brick Bug Thread

[ThaiDai]

Sorry, das ist Blödsinn.
Der User schrieb:

Kommt besser nicht auf die Idee das Trimmen mit dem Note N7000
auszuprobieren. Das bedeutet nämlich einen totalen Brick eures Notes
aufgrund eines ab Werk defekten Speichercontrollers, der den Flash
Speicher dabei dauerhaft zerstört.

Also kein Brick, den er selbst erlebt hat. Er hat nur eine Behauptung (Zusammenhang Trim und den fehlerhaften eMMC-Chips) aufgestellt. Ob das wirklich so ist, wäre dann erst mal zu beweisen. Da aber die meisten Kernels mittlerweile sicher sind (also den Bug umgehen), sollte doch wohl auch ein Trim-Befehl analog arbeiten.

Ergänzung:
Habe im Entwicklerthread in XDA mal die Info zum Artikel gepostet aber auch Richtung Entwickler die Frage gestellt, ob da überhaupt ein Zusammenhang bestehen kann. Und natürlich hoffe ich zudem auf eine Info, ob fstrim in CM10.2 auch für das N7000 aktiviert ist - dann können wir ja mal wirklich mit einem dauerhaft "lagfreien" Rom rechnen - das wäre ein wirklicher Fortschritt.

 

[frank_m]

Ich halte diese Aussage für höchst spekulativ.

Die Ursache für den damaligen Brick Bug lag ja ausschließlich in Custom Recoveries. In den Custom Kerneln bzw. Recoveries kann man die Verwendung durch Deaktivierung von MMC_CAP_ERASE umgehen. Samsung Stock ROMs hatten ja nie ein Problem mit dem Brick Bug.

Statt dessen ist aber sicher, dass das MMC_CAP_ERASE im Kernel nur eingeführt wurde, um TRIM effizient verwenden zu können. Siehe die damaligen Analysen von Entropy512 zum Thema. Die Aussage kam von den Samsung Entwicklern, mit denen er sich damals getroffen hat (nachzulesen in seinem Google+ Blog). Es hieß auch, dass Samsung seit den ICS ROMs TRIM aktiviert hat.

Es gibt TRIM ja auch als User App. Wie sieht es denn damit aus?

 

[ThaiDai]

Habe nun mal im Store nach der Trim-App gesucht:
LagFix nutzt fstrim und verweist vom Playstore auf den folgenden Thread in XDA "Warning"

WARNING!
There are some devices affected by BrickBug. Samsung Galaxy S2 and Samsung Galaxy Note are known to have it....
...BrickBug means DEATH of your device if you try LagFix! There are some unlucky guys already.

Das ist für mich immer noch kein Beweis - allerdings würde ich nun meine Aussage "Blödsinn" von zuvor deutlich zurückhaltender formulieren.
Eine Aussage im XDA-CM10.2-Developerthread vom Entwicklerteam zur Frage hat es noch nicht gegeben. Mal schaun, ob die ein Statement dazu abgeben.

Update 31.07.2013
Nachdem xplodwild den Developer Thread dank der wertvollen Beiträge der XDA-Community bereits geschlossen hat, habe ich ihm ein PM zum Thema (fstrim ist in 4.3 und schreibt auf den eMMC) geschickt. Er leitet die Frage an Entropy512 weiter, da dieser der eMMC-Fachmann sei. Hoffen wir mal, dass hier Entwarnung kommt.

Er hat geantwortet: es besteht kein Risiko, da eben CAP_MMC_ERASE in den aktuellen Kernels disabled ist. Das bedeutet aber wohl auch, dass wir den Trim-Vorteil in 4.3 nicht bekommen und weiter mit zunehmenden Lags vorlieb nehmen müssen (fstrim funktioniert wohl nur, wenn "enabled"). Schade aber auch.

 

[frank_m]

es besteht kein Risiko, da eben CAP_MMC_ERASE in den aktuellen Kernels disabled ist.

Auch in den Stock Kerneln? Auf Cyanogen Mod (=> was ja wohl die Basis für ein Android 4.3 auf dem Note wäre) ist das natürlich richtig.

Das bedeutet aber wohl auch, dass wir den Trim-Vorteil in 4.3 nicht bekommen und weiter mit zunehmenden Lags vorlieb nehmen müssen (fstrim funktioniert wohl nur, wenn "enabled"). Schade aber auch.

Das sehe ich anders.

Das MMC_CAP_ERASE ist ein Feature des MMC Controllers, welches es erlaubt, Blöcke im Hintergrund durch den Controller löschen zu lassen. Man übergibt ihm die Liste der zu löschenden Blöcke, und er kümmert sich um den Rest. Ist MMC_CAP_ERASE nicht aktiv, dann muss das Löschen der Blocke "von Hand", also durch die Software des MMC Treibers im Kernel, erledigt werden. Man kann sich den Code für das Löschen im Kernel Source Code ansehen, dass nicht mit einkompliert wird, wenn das Flag MMC_CAP_ERASE aktiv ist (hab ich damals mal gemacht, als ich den Brick Bug analysiert hab. Müsste noch hier im Thread stehen).

Das bedeutet demzufolge, dass Löschvorgänge auf dem Flash effizienter werden, wenn MMC_CAP_ERASE aktiv ist. Das gilt sowohl für die Zeit als auch für die Energie, die dafür aufgewendet werden muss. Es ist naheliegend, dass es weniger Energie verbraucht, wenn der Prozessor schlafen kann, während das Flash gelöscht wird, als wenn der Prozessor beim Abarbeiten der Lösch-Routinen aktiv sein muss.
Es ist dabei aber egal, ob Blöcke durch TRIM gelöscht werden oder vor dem Überschreiben gezwungenermaßen gelöscht werden müssen. Beides flutscht besser mit MMC_CAP_ERASE, weil eben ohne Prozessorbeteiligung.

Das bedeutet aber auch: TRIM kann auch ohne MMC_CAP_ERASE funktionieren. Allerdings muss das Gerät aus dem Deep Sleep aufwachen, um die Blöcke zu löschen. Das wäre aber machbar, so lange dauert es auch nicht, wohl nur wenige Sekunden pro GB.

Allerdings muss man sagen, dass das TRIM Feature des Linux Kernels nicht das Gelbe vom Ei ist. Es versucht nämlich immer sofort nach der Löschmarkierung eines Blocks, diesen auch physikalisch zu löschen. Ohne MMC_CAP_ERASE würde dadurch eine kleine Wartezeit auf dem Note entstehen, sobald man eine Datei löscht. Man würde die Lags also nur verschieben: Vom Zeitpunkt des Schreibzugriffs auf den Zeitpunkt der Löschaktion. Das Ergebnis wäre das gleiche.

Deshalb wird auf Linux eigentlich generell davon abgeraten, das TRIM durch den Kernel (=> als Mount Option) ausführen zu lassen und es statt dessen lieber einmal täglich als Cron Job machen zu lassen (z.B. mit fstrim). Die Empfehlung gilt auch für SSDs. Ich weiß jetzt nicht genau, wie das TRIM Feature von Android 4.3 aussieht. Wenn das ein Hintergrunddienst ist, der manuell bei bestimmten Ereignissen oder zu bestimmten Zeitpunkten die TRIM Operation durchführt, dann spricht nichts dagegen, dass auch auf einem Note ohne MMC_CAP_ERASE ausführen zu lassen. Es würde im Hintergrund bei Display Off laufen und nur ein wenig Deep Sleep kosten. Aber die Lags wären trotzdem weg.

Wenn es allerdings als Mount Option mit Kernel TRIM realisiert wird, dann sollte man es auf einem Note ohne MMC_CAP_ERASE nicht aktivieren.

//Nachtrag: Die Pro Version von LagFix kann offensichtlich zeitlich gesteuerte TRIM-Vorgänge vornehmen, z.B täglich um 3:00 Uhr oder so. Das wäre ideal.

 

[ThaiDai]

Es ist naheliegend, dass es weniger Energie verbraucht, wenn der Prozessor schlafen kann, während das Flash gelöscht wird, als wenn der Prozessor beim Abarbeiten der Lösch-Routinen aktiv sein muss.

Zum schlafenden Prozessor und Deinen weiteren Deep-Sleep-Aussagen während des Trims möchte ich einfach einen Codeausschnit aus fstrim.c und den zugehörigen Kommentar posten:
Dort wird ausdrücklich ein wakelock gesetzt, damit der Prozessor während des Trims auf keinen Fall schlafen geht.

Und nun warte ich einfach mal ab, ob der zumindest in XDA als eMMC-Guru geltende Entropy512 noch eine Bewertung dazu abgibt.

int fstrim_filesystems(void)
{
    pthread_t t;
    int ret;

    /* Get a wakelock as this may take a while, and we don't want the
     * device to sleep on us.
     */
    acquire_wake_lock(PARTIAL_WAKE_LOCK, FSTRIM_WAKELOCK);

    /* Depending on the emmc chip and size, this can take upwards
     * of a few minutes.  If done in the same thread as the caller
     * of this function, that would block vold from accepting any
     * commands until the trim is finished.  So start another thread
     * to do the work, and return immediately.
     *
     * This function should not be called more than once per day, but
     * even if it is called a second time before the first one finishes,
     * the kernel will "do the right thing" and split the work between
     * the two ioctls invoked in separate threads.
     */
    ret = pthread_create(&t, NULL, do_fstrim_filesystems, NULL);
    if (ret) {
        SLOGE("Cannot create thread to do fstrim");
        return ret;
    }

    ret = pthread_detach(t);
    if (ret) {
        SLOGE("Cannot detach thread doing fstrim");
        return ret;
    }

    return 0;
}

 

[Smartsurfer]

Samsung Stock ROMs hatten ja nie ein Problem mit dem Brick Bug.

Sicher? Ich meine mich zu erinnern, dass in Foren von zahlreichen gebrickten Notes in Verbindung mit Stock 4.04 berichtet wurde, wenn von dieser Version aus weitere ROMs geflasht wurden. Deswegen kam doch später immer die Aussage, dass in diesem Fall unbedingt ein sicherer Kernel verwendet werden muss.

 

[MichelFell]

Wie willste denn mit dem Stockkernel eine weitere Rom flashen? Brauchst doch erst mal CWM, also nen' Customkernel und ab da geht das Risiko erst los.

 

[Smartsurfer]

Wie willste denn mit dem Stockkernel eine weitere Rom flashen? Brauchst doch erst mal CWM, also nen' Customkernel und ab da geht das Risiko erst los.

Glaube das stimmt so nicht ganz, denn der ICS Kernel ist wohl das Übel

How to Avoid EMMC Brick on Galaxy Note N7000 to Easily Factory Data Reset and Install ICS Custom ROM

EMMC brick has caused many users to permanently brick their Galaxy Note and it would not turn on at all then. Why? Apparently, Galaxy Note N7000 units have been shipped with faulty EMMC chips. That, when trying to factory reset or full wipe your phone using ClockworkMod recovery or any recovery using Samsung stock ICS kernel as base, it will brick Galaxy Note permanently.

Ob Samsung das in späteren Kernels wieder gefixt hat weiß ich nicht.

 

[frank_m]

Smartsurfer, die Informationen sind veraltet. Das steht auch schon im Thread hier. Schau dir die Analysen von Entropy512 auf seinem Google+ Blog aus dem letzten November an.

Samsung Stock Kernel und Stock Recovery hatten nie ein Problem mit dem Brick Bug. Das Problem konnte nur durch die Verwendung eines Custom Recoverys in Verbindung mit einem Stock Kernel auftreten, oder um präzise zu sein: Durch die Verwendung einer fehlerhaften libext4 für das Bauen des Recovery Binaries.

Entropy512 hat sich damals mit Samsung Entwicklern getroffen und das Verhalten analysiert. Klare Aussage der Entwickler damals: MMC_CAP_ERASE verbessert die Performance und die Akkulaufzeit und bleibt folglich drin. Ob es dann Probleme mit Custom Software gibt, ist denen egal, solange es mit Samsung Stock Software stabil läuft. Auf die Community wird da keine Rücksicht genommen.

Wenn du noch mal weiter vorn in diesen Thread schaust, dann hab ich schon im Sommer letzten Jahres bezweifelt, dass die ursprünglichen Theorien, Samsung Kernel seien schuld, noch stimmen. Mir war da schon auf Basis der Nutzer-Rückmeldungen aufgefallen, dass die Brick Fälle immer nur bei der Erstinstallation von Custom ROMs auftraten, aber nicht bei Wipes auf Stock ROMs. Wenn die anfänglichen Theorien gestimmt hätten, dann hätte es genau umgekehrt sein müssen.
Im Nachhinein hat sich das bestätigt: Genau die Erstinstallation eines Custom ROMs wird in den meisten Anleitungen mit einem Custom Recovery auf einem Stock Kernel vorgenommen und war damit besonders gefährlich. Das wurde aber erst im November 2012 bewiesen.

 

[Smartsurfer]

Ich mag das gerne glauben. Aber ist damit auch das Trimmen unter Stockkernel (bzw. Philz?) sicher? Auch unter CM dürfte dann doch theoretisch nichts passieren, auch wenn das Trimmen dann vielleicht einfach nicht klappt.

Aber irgendwie gibt es nirgends im Netz eine positive Meldung dazu.
Bisher hört man nur gegenteiliges, insbesondere von den Entwicklern der Trimsoftware, wie auch schon weiter oben zitiert.

Was mich allerdings wundert, Android Tuner hat seit einiger Zeit auch die Trimfunktion eingebaut und kann dort aktiviert werden. Obwohl ich da bisher nirgends eine Warnung finden konnte, habe ich es mich noch nicht getraut...

 

[frank_m]

Aber ist damit auch das Trimmen unter Stockkernel (bzw. Philz?) sicher?

Unter Phliz auf jeden Fall, denn da ist MMC_CAP_ERASE deaktiviert. Ob auf einem Stock Kernel, kann man im Moment nur vermuten. Wenn dieses Trim Binary genau das gleiche macht, was damals die fehlerhafte libext4 machte, dann kann es auf Stock Kerneln gefährlich sein.

Auch unter CM dürfte dann doch theoretisch nichts passieren, auch wenn das Trimmen dann vielleicht einfach nicht klappt.

Richtig. Trimmen wird man auf jeden Fall können. Die Frage ist nur, wie lange es dauert.

 

[Smartsurfer]

Wer traut sich?

 

[Jockel70]

Hmm, ich würde das Risiko eingehen, mein Note mit Lagfix zu trimmen. Habe es gerootet (PhilZ-cwm6-XXLT4-OXA-4.93.6-signed), aber LagFix will nicht installieren. Und wenn ich die Lagfix-APK runterlade und aufrufe, sagt er mir, dass mein Device das gar nicht unterstützt. "Operation not supported on transport endpoint"

Ist das noch eine Einschränkung von LagFix, dass er sich also nicht traut, das bei mir anzuwerfen? Oder gibt's mein Kernel tatsächlich nicht her?

Weiß jemand Abhilfe?

(Mein Note ist mir eh gerade runtergefallen und die Scheibe ist hin... genau der richtige Zeitpunkt, um den Trim vor der Reparatur mal auszuprobieren ;-)

Viele Grüße, Jörg

 

[Smartsurfer]

Du könntest die App Android Tuner verwenden, die kann seit einiger Zeit auch trimmen. Ob es die Free Version unterstützt weiss ich allerdings nicht.

 

[Jockel70]

Heyho, jau, Android Tuner kann auch in der Free-Version trimmen. Allerdings geht das so sackschnell beim Note, dass ich mir kaum vorstellen kann, dass da wirklich was passiert.

Immerhin aber die gute Nachricht: Es läuft, kein Brick.

Dem Gefühl nach ist es nun etwas schneller, aber irgendwie kam es mir anfangs (bzw. direkt nach einem Wipe) immer noch schneller vor. Ist aber schwer zu sagen und leider so gut wie gar nicht zu messen...

 

[frank_m]

Allerdings geht das so sackschnell beim Note, dass ich mir kaum vorstellen kann, dass da wirklich was passiert.

Das muss nicht lange dauern. Vor allem, wenn man es regelmäßig benutzt, ist es sehr schnell erledigt.

 

[tobi3]

Darf ich kurz fragen was mit Trimmen gemeint ist ? Gruß Tobi

Gesendet von meinem GT-N7000 mit Tapatalk 2

 

[fragi]

Guckst du hier:

https://www.android-hilfe.de/forum/...k-bug-thread.240563-page-37.html#post-6173157

Ist da eigentlich recht breit erklärt (und nur eine Seite zurück)

 

[Conian]

Hallo,

vielleicht kann mir jemand weiterhelfen... Mein Note ist momentan auf Stock-ICS, gerootet damals mit der Chainfire-Methode - was sich ja im nachhinein als die aller schlechteste Kombi im Zusammenhang mit dem Brick-Bug herausgestellt hat
Nun würde ich aber gerne mal was Neues ausprobieren und zu Cyanogenmod 10.1 wechseln. Nachdem ich mich jetzt so viel wegen dem Bug eingelesen habe, habe ich nicht nur Kopfschmerzen sondern bin auch total verunsichert^^
Reicht es aus wenn ich einen sicheren Kernel wie z.B. Philz vorher flashe, dann einen factory-reset mache und anschließend nach der Anteiltung des Roms vorgehe, oder gibt es da noch einen weiteren Zwischenschritt um die Risiken zu minimieren?
Oder doch besser ein Downgrade auf GB und von da aus mit den Spielerein anfangen?

 

[Jrp Defy]

Du kannst gleich den 10.1 nx Kernel im recovery flashen ohne wipe, dann auf advanced und auf reboot recovery.
Dann erst alle wipes ausführen, bei dem nx Kernel reicht es auch auf Data wipe zu gehen und flash new rom wipe, dann hast du alle notwendigen wipes.
http://www.mediafire.com/?0p1do44rqfur5

Nimm entweder den neuesten oder 1.4.2

Davor natürlich erst die 10.1 rom und gapps deiner Wahl auf der sd Karte ablegen.


Edit: den geeigneten philz kannst du auch nehmen, nur ab und an kommt es von einem tw Kernel zu cm Flash zu einem Status 7 und es geht nicht weiter, deswegen lieber den nx nehmen, der hat ja die recovery vom philz!