Der Brick Bug Thread

[syscrh]

... Also, ich hatte zwei HTC Geräte, die beide sehr gut funktionierten, habe damit nie Probleme gehabt, und geflasht habe ich da auch. ...

Aber das HTC One X hat z. B. ziemliche Lack-Probleme.

Ich sage ja auch nicht, das Samsung schlecht ist, das Note ist gut, sicher, auch dieses Display usw., nur halt wenn Geräte mit kaputtem Chip zurückkommen, sollte sich ein Hersteller schon überlegen einen vernünftigen Chip einzubauen, so sehe ich das zumindest.

Da muss ich Dir zustimmen. Allerdings: Ich habe (ausversehen) wieder etwas falsch geflasht (hätte eigentlich ein Hard-Brick sein müssen) und hatte danach keinen Brick. --> Der Chip ist etwas weniger gefährdet. Aber ärgern tut mich das auch.

 

[cheezusweezel]

Fakt bleibt aber auch, wenn man weiß was man tut bzw. darauf achtet, muss auch trotz gefährdetem Chip und mehr als 100 Flashvorgängen nichts passieren.

 

[syscrh]

Fakt bleibt aber auch, wenn man weiß was man tut bzw. darauf achtet, muss auch trotz gefährdetem Chip und mehr als 100 Flashvorgängen nichts passieren.

Und beim 101 mal ist man dann abgelenkt und es passiert was.

 

[blubenow]

Und beim 101 mal ist man dann abgelenkt und es passiert was.

Natürlich, da gebe ich Euch recht, das ist klar.

Der ursprüngliche Beitrag von 18:17 Uhr wurde um 18:20 Uhr ergänzt:

Aber das HTC One X hat z. B. ziemliche Lack-Probleme.





Da muss ich Dir zustimmen. Allerdings: Ich habe (ausversehen) wieder etwas falsch geflasht (hätte eigentlich ein Hard-Brick sein müssen) und hatte danach keinen Brick. --> Der Chip ist etwas weniger gefährdet. Aber ärgern tut mich das auch.

Das Gerät wollte ich erst haben, aber wie ich gelesen habe, dass der Akku fest verbaut ist, habe ich davon Abstand genommen, ein Akku ist schnell mal kaputt.

 

[fragi]

Fakt ist doch auch, dass nicht der Chip kaputt ist, sondern die Art und Weise wie er unter ICS angesprochen wird, zu einem ungewünschten Verhalten führt...

Ist wahrscheinlich eher vergleichbar mit einem Auto, bei dem die Gangschaltung so blöd verbaut ist, dass man unter Umständen mal versehentlich bei 180 in den Rückwärtsgang schalten kann...

 

[cheezusweezel]

So sieht's aus ... Wobei den falschen Gang einlegen nicht gegen die Garantie verstößt, LOL.

 

[frank_m]

Leute, jetzt lasst mal die Kirche im Dorf. Ihr tut ja fast so, als ob Samsung absichtlich irgendwelche Bricks provoziert. Das ist - wenn überhaupt - ein Bug im Kernel im Zusammenspiel mit der Firmware eines Chips.

Und nach wie vor bleibt klar festzuhalten, dass eigentlich alle Bricks im Umfeld von riskanten Flashaktionen aufgetreten sind. Die anfänglich mal ausgegebenen Verhaltenstipps gelten dabei schon lange nicht mehr. Wenn man sich mal die Berichte der letzten Wochen bei uns im Forum und bei xda-developers ansieht, dann fällt folgendes auf:

• Es hat auch reichlich erfahrene Nutzer und ROM Köche getroffen, die definitiv wissen, was sie tun und welche Vorsichtsmaßnahmen sie ergreifen müssen. Da hat auch Zurückflashen auf GB Kernel vorm Wipe oder sichere Recoverys etc. am Ende nicht geholfen. Das sind aber die Verhaltensweisen, die den Brick Bug des Chips sicher umgehen. Wieso tritt er trotzdem auf?
  Die Leute haben sehr viel geflasht, und irgendwann hat es sie erwischt. Bleibt die Frage: War es da jedesmal der Brick Bug? Jeder Flashvorgang birgt das Risiko, sein Gerät zu bricken. Je öfter man es macht, desto größer die Gefahr. Vielleicht war es ein anderer Schaden?
• Die meisten Bricks sind eindeutig im Umfeld CM bzw. AOSP ROMs aufgetreten. Die Kernel gelten zwar als sicher, und die Anleitungen sind angeblich so ausgelegt, dass nichts passieren kann. Dennoch bricken die Leute ihre Geräte, auch wenn sie anschließend beschwören, sich exakt an die Anleitungen gehalten zu haben. Rein statistisch ist das momentan am gefährlichsten, besonders der Wechsel von Stock auf AOSP. Es ist bemerkenswert, dass ausgerechnet die ROMs am gefährlichsten sind, von denen die Devs behaupten, sie würden den Brick Bug des Chips umgehen.
• In den Firmwarethreads berichten ne Menge Leute davon, problemlos ihre Geräte gewiped zu haben - trotz ICS Kernel. Das hingegen wird eigentlich als ein mehr oder weniger sicheres Todesurteil beschrieben.
• Es gibt einige Berichte von Leuten, die ihr Gerät bei einem offiziellen Samsung Update gebrickt haben. Die Quote ist aber extrem gering im Vergleich zu den Brick Fällen im Custom ROM Umfeld. Sie ist eigentlich nicht höher, als vor den ICS Firmwares, denn auch da gab es schon Fälle von schief gelaufenen Samsung Updates.

Unterm Strich fällt auf, dass die Bricks eigentlich ausschließlich bei Aktionen auftreten, die Samsung so nicht vorgesehen hat. Bei Leuten, die sich ausschließlich im Samsung Stock Umfeld bewegen, ist die Quote hingegen sehr gering. Und dabei sollen es doch gerade die Samsung Kernel und Recoverys sein, die gefährlich sind. Irgendwas passt da nicht.

Was noch erschwerend hinzukommt: Andere Geräte, wie z.B. die aktuellen Galaxy Tabs, benutzen den gleichen Flash Chip und die gleichen Kernel-Optionen. Von einer außergewöhnlichen Häufung von Bricks liest man da aber nichts. Die Custom ROM Landschaft für diese Geräte ist aber auch nicht sonderlich ausgeprägt.

Was war eigentlich der Auslöser für die Brick Bug Diskussion? Richtig ist, dass die Quote an Bricks beim Note viel höher ist, als bei anderen Geräten. Den Custom ROM Devs bei xda fiel auf, dass es plötzlich mit ICS Custom ROMs eine größere Anzahl Bricks gab, als vorher. Daraufhin haben sie angefangen zu suchen und sind irgendwann auf dieses ERASE Kommando des Flash Chips gekommen. Ob das aber tatsächlich der Auslöser ist, hat so richtig auch noch niemand bewiesen. Momentan sprechen die Umstände der auftretenden Bricks halt eine andere Sprache: Die Leute, die sich vor diesem ERASE Kommando hüten, wie der Teufel vorm Weihwasser, bricken ihre Geräte, und die Leute, die es regelmäßig benutzen, nicht.

Samsung weiß über den Bug Bescheid, und zwar seit Monaten. Das sie schnell reagieren können, wenn sie über einen Bug Bescheid wissen, haben sie beweisen. Die zergrush Lücke war zwei Wochen nach dem Auftreten in den Firmwareupdates zu. Den Bug der Google Suche hatten sie auf dem S3 nach 2 Tagen gefixt. Und ein solches Problem, das seit 4 Monaten bekannt ist, und potentiell tausende Geräte zerstört - und zwar originale Samsung Geräte, die unter Garantie fallen - das lösen sie nicht?

Irgendwas stimmt da nicht. Ich denke, wir müssen in Sachen Brick Bug noch mal von vorn anfangen. Die bisher kolportierte Lösung ist es offensichtlich nicht, denn dann müssten sich die Brick Fälle der vergangenen Wochen genau anders herum darstellen. Ich hab das Thema auch bei xda schon ein paar mal angeschnitten, und mittlerweile schlagen sich einige auf meine Seite. Es gibt zwar immer noch starke Verfechter des Samsung Bugs, aber die Frage ist, ob das nicht überwiegend der Bequemlichkeit geschuldet ist. Es ist halt einfacher, den Bug Samsung in die Schuhe zu schieben, anstatt selber zu suchen.

 

[cheezusweezel]

Frank, ich bin ja in 9 von 10 Fällen deiner Meinung, aber CM als "gefährlicher" als ICS darzustellen, kann ich zu 0% unterschreiben.

Nach meiner persönlichen Meinung, besteht dort absolut KEINE Gefahr. Falls es im Zusammenhang mit CM zu Bricks kam, dann ganz genau wie Du es auch gesagt hast, weil man von ICS (mit Gefährdung) auf CM gewechselt hat und dann eben noch mit dem ICS-Kernel formatiert wurde, o.ä. !

Von GB auf CM oder von CM auf CM gab es meines Wissens noch nie einen Brick, der in das Chip-Dilemma passt.

 

[frank_m]

Wie gesagt, die Leute behaupten, alles richtig gemacht zu haben. Gut, das behaupten alle, aber es waren auch welche dabei, die nicht zum ersten Mal von Stock auf AOSP gewechselt sind. Ob die sich alle irren? Schwer zu glauben.

Was ich einfach nur noch mal deutlich machen will: Die bisher beschriebene Ursache und die tatsächlich auftretenden Fälle passen einfach nicht mehr zusammen. Das ging in den ersten Wochen, und als die ersten seriös aussehenden Erklärungen aufkamen, hat auch jeder gesagt "ja siehste!". Aber mittlerweile laufen die Zahlen einfach zu sehr auseinander, als das man es noch länger ignorieren könnte.

Es kommt noch was hinzu, was ich oben noch vergessen habe: Die Symptome passen nicht mehr zusammen. Früher konnte man den Brick Bug einfach am Verhalten von Odin erkennen, wenn an spezifischen Stellen im Flashvorgang der Abbruch kam. Heute ist das in vielen Fällen anders. Die heute häufig beschriebenen Symptome beim Flash mit Odin passen nicht mehr zum ursprünglich beschriebenen Brick Bug bzw. zum Verhalten, das auftreten müsste, wenn sich der Flash Chip so verhält, die z.B. Entropy es in seiner Analyse beschreibt.

Es geht mir ja nicht darum, hier irgendjemanden in Schutz zu nehmen. Du weißt selber, wie oft ich an entsprechender Stelle vorm Brick Bug gewarnt habe. Aber wenn ich dann Leuten, die das definitiv gewusst haben, aus einem Brick heraushelfen muss, dann stelle ich mir die Frage: Was geht hier gerade schief? Die Warnungen, die wir momentan ausgeben, gelten in dieser Form einfach nicht mehr bzw. sind wirkungslos. Also muss ich noch mal neu anfangen, darüber nachzudenken, denn das, was momentan abgeht, kann es nicht sein.

 

[cheezusweezel]

Das kann ich wieder 100% unterschreiben ... Mittlerweile ist das irgendwie ein komplexeres Problem und man kann nicht mehr einfach vor Schema F warnen. Mal sehen was JB bringt, hoffen darf man ja schließlich immer.

 

[syscrh]

... Samsung weiß über den Bug Bescheid, und zwar seit Monaten. Das sie schnell reagieren können, wenn sie über einen Bug Bescheid wissen, haben sie beweisen. Die zergrush Lücke war zwei Wochen nach dem Auftreten in den Firmwareupdates zu. Den Bug der Google Suche hatten sie auf dem S3 nach 2 Tagen gefixt. Und ein solches Problem, das seit 4 Monaten bekannt ist, und potentiell tausende Geräte zerstört - und zwar originale Samsung Geräte, die unter Garantie fallen - das lösen sie nicht? ...

Evtl. hat Samsung selbst ja noch nicht einmal die wirklich Ursache gefunden?! --> Wie soll Samsung den Fehler denn dann beheben?

 

[frank_m]

Evtl. hat Samsung selbst ja noch nicht einmal die wirklich Ursache gefunden?!

Wenn das der Fall ist, dann sind auch alle Analysen der Community falsch, denn die Ursache ist angeblich eindeutig die Verwendung des Kommandos "MMC_CAP_ERASE" im Kernel, womit der Flash Chip nicht zurecht kommt. Die Lösung wäre also einfach, das MMC_CAP_ERASE Kommando wieder zu deaktivieren, wie es unter GB der Fall war. Das ist ein einfaches Statement im Code, die ganzen Custom Kernel und AOSP Kernel haben es ja auch deaktiviert. Das ist in zwei Sekunden eingefügt, dann noch einmal Kernel neu kompilieren und fertig: Der Bug wäre Geschichte. Alle bisherigen Workarounds der Custom ROM und AOSP Entwickler basieren darauf, dieses MMC_CAP_ERASE zu vermeiden.

Fürs Note DBT gibt es mittlerweile 3 offizielle ICS Firmwares. Wenn die erste vielleicht noch den Bug hatte (nachdem er ja schon bei den inoffiziellen China Leaks identifiziert wurde), wäre es in allen folgenden nicht mehr erforderlich gewesen. Das MMC_CAP_ERASE ist aber auch in der LRK noch drin. Das ist für mich auch ein Beleg, dass es nicht so einfach ist, wie sich das einige Custom ROM Entwickler im Moment wünschen.

 

[trahzebuck]

Interessante Diskussion.

Ich glaube es ist müssig über die Motive von Samsung zu diskutieren. Abgesehen davon dass die grade mal wieder mit Apple beschäftigt sind, sind wir hier im spekulativen bereich.

Fact ist, das der MMC_Brick-Dings ein Problem darstellt. Aber eben nur bei bestimmten Rev.-Ständen des Chips. Von der GetBrickBug-App von CF wissen wir aber, das es mehrere Stände gibt. Weiss der Geier, auf welche Situationen diese Chips dann allergisch reagieren.

Wie cheezusweezel bin ich der Meinung, dass CM9/10 in keinster Weise gefährlicher ist als Sammy-ICS. Es liegt wohl eher daran, dass hier sorgloser umgegangen wird, weil wir haben ja einen safe-kernel und flashen auf Teufel komm raus. Ich glaube dass auf der Stock/Sammy Seite mittlerweile einfach vorsichtiger vorgegangen wird.

Und die Hauptursache bleibt immer noch der DAU. Bin selbst vor ein paar Tagen bei flashen fast eingeschlafen (nicht lachen) und hätte beinahe mit CF-Kernel gewiped. Tja und ob sowas dann wirklich ehrlich gepostet wird. Von einem erfahrenen User....

 

[CreamDrioD]

Interessante Diskussion.

Ich glaube es ist müssig über die Motive von Samsung zu diskutieren. Abgesehen davon dass die grade mal wieder mit Apple beschäftigt sind, sind wir hier im spekulativen bereich.

Fact ist, das der MMC_Brick-Dings ein Problem darstellt. Aber eben nur bei bestimmten Rev.-Ständen des Chips. Von der GetBrickBug-App von CF wissen wir aber, das es mehrere Stände gibt. Weiss der Geier, auf welche Situationen diese Chips dann allergisch reagieren.

Wie cheezusweezel bin ich der Meinung, dass CM9/10 in keinster Weise gefährlicher ist als Sammy-ICS. Es liegt wohl eher daran, dass hier sorgloser umgegangen wird, weil wir haben ja einen safe-kernel und flashen auf Teufel komm raus. Ich glaube dass auf der Stock/Sammy Seite mittlerweile einfach vorsichtiger vorgegangen wird.

Und die Hauptursache bleibt immer noch der DAU. Bin selbst vor ein paar Tagen bei flashen fast eingeschlafen (nicht lachen) und hätte beinahe mit CF-Kernel gewiped. Tja und ob sowas dann wirklich ehrlich gepostet wird. Von einem erfahrenen User....

Hab mal nach dem Flashen die Micro-SD in den Sim- Schacht gesteckt. War auch nicht lustig.

Gesendet von meinem GT-N7000 mit der Android-Hilfe.de App

 

[cheezusweezel]

LOL ...

 

[frank_m]

Vielleicht sind die CM ROMs nicht gefährlicher, wenn man sie erst mal im Betrieb hat. Fakt ist aber, dass beim Wechsel von Stock auf CM im Moment mit Abstand die meisten Bricks auftreten. Das kann niemand wegdiskutieren. Da aber alle Flashanleitungen angeblich das Brickproblem berücksichtigen, kann da irgendwas nicht stimmen.

Ich hab auch noch keine Idee, was da wirklich eine Rolle spielt. Ich bin nur der Meinung, dass wir das Problem noch nicht vollständig durchschaut haben und dass die momentanen Vorsichtsmaßnahmen nicht hinreichend bzw. sogar falsch sind.

 

[user_99]

Ich bin überzeugt, dass die ROMs per se sicher sind. Bleibt man beim originalen ROM kann man wipen so viel man will. Es wird nichts passieren. Problematisch wird es bei den Custom Roms und da glaube ich hat es bei den eingesetzten Update scripts das eine oder andere Problem gegeben. Ich kann mich an eine Meldung eines bekannten Devs erinnern, der sein Note zerstört hat, da er eben vergessen hat in besagtem script den Teil fürs emmc löschen zu ändern übersehen hat. Jetzt schaut es ja wieder besser aus und diejenigen, die die OP der Rom nicht lesen und wild drauf los flashen kann nicht geholfen werden

 

[blubenow]

Ich bin überzeugt, dass die ROMs per se sicher sind. Bleibt man beim originalen ROM kann man wipen so viel man will. Es wird nichts passieren. Problematisch wird es bei den Custom Roms und da glaube ich hat es bei den eingesetzten Update scripts das eine oder andere Problem gegeben. Ich kann mich an eine Meldung eines bekannten Devs erinnern, der sein Note zerstört hat, da er eben vergessen hat in besagtem script den Teil fürs emmc löschen zu ändern übersehen hat. Jetzt schaut es ja wieder besser aus und diejenigen, die die OP der Rom nicht lesen und wild drauf los flashen kann nicht geholfen werden

Moment, bei den originalen ICS Roms kam es doch auch zu Bricks, nicht nur bei Custom Roms

 

[frank_m]

Moment, bei den originalen ICS Roms kam es doch auch zu Bricks

Ja, aber wie oft denn? Zeige mir die Fälle, die wirklich ausschließlich mit Stock ROMs gebrickt haben. Ich kenne drei Fälle: Zwei mit GB und einen mit ICS. Beim Rest waren Custom ROMs im Spiel.

 

[blubenow]

Also bei mir ist es bei der Kies Rom passiert. Ich hatte im Vorfeld mehrere Custom Roms drauf.Ich wollte es auf original Software zurückflashen habe über GB, dann Kies geupdatet. Es lief dann nicht richtig, und ich habe ein Fullwipe gemacht, dann war der Chip hin.