Der Brick Bug Thread

[marcodoncarlos]

have mein handy im cvm abgeschossen, da akku raus war.
nun meine frage, ich hatte eine stockrom aber gerootet drauf, sollte ich jetzt auf garantie verzichten und 70 löhnen oder es einfach probieren? bezogen auf den 1.ten post.

da ich nun mittels jig und 3 tastenkombi nicht in den downloadmodus komme.

 

[usaris]

Auf XDA gibt es einen Thread über eine App, die den emmc Chip liest, und aus dem erfolgreichen Lesen ableitet, ob der Chip (bereits) fehlerhaft ist oder nicht.

Link zum Thread:
[Application] eMMC Check. Check if your phone is damaged. - xda-developers
Link zur App https://play.google.com/store/apps/details?id=net.vinagre.android.emmc_check

Die App braucht root.
Das Ergebnis kann man anscheinend daran ablesen: Hängt sich die App auf, dann geht'S dem Chip ned so gut, läuft sie durch, alles paletti. (Ob das Durchlaufen in jedem Fall ein "Alles OK" bedeutet, ist mir nach dem Lesen mehrerer Beiträge im Thread nicht 100% klar.)
Man darf, während der Test läuft nicht den Screen berühren oder das Gerät drehen, sonst stoppt die App.
Es wird ein Lesefortschritt angezeigt.
Es werden sehr unterschiedliche Durchlaufzeiten berichtet, von 100 s bis 600 s. Ein User schreibt, dass unter 300 s nicht realistisch sein kann. Bei mir dauert es ca 600 s. Ich vermute, dass es am Befüllungsgrad des Chips liegt. Wenn alles voll ist, dauert es länger.

Wer sich die App nicht installieren möchte und Unix Shell Command firm ist, kann den Befehl auch so absetzen

To test your emmc just can do (as root of course)
time dd if=/dev/block/mmcblk0 bs=1M of=/dev/null
Then wait.... you'll see if you get any errors.
Link ist hier xda-developers - View Single Post - [Application] eMMC Check. Check if your phone is damaged.

Wenn sich das Teil beim Lesen aufhängt (Beileid), dann hilft ein Batterie rausnehmen und etwas abwarten vor dem Neustart. Ja, und ab dann vorsichtig sein, mit Samsung reden, oder was weiß ich

 

[frank_m]

Ok. Wenn ein dd Lesefehler erzeugt, dann ist das Gerät defekt. Da gibt es keine zwei Meinungen. Aber: Wenn es so weit ist, dann brauche ich eigentlich keine App mehr, um festzustellen, dass es ein Problem gibt.

 

[niko26]

Ah, Mist.. einen Tag zu spät

 

[usaris]

Ok. Wenn ein dd Lesefehler erzeugt, dann ist das Gerät defekt. Da gibt es keine zwei Meinungen. Aber: Wenn es so weit ist, dann brauche ich eigentlich keine App mehr, um festzustellen, dass es ein Problem gibt.

Was genau möchtest du damit sagen?

Soweit ich verstanden habe, können die fehlerhaften Sektoren durch den "Brickbug" am Anfang des Chips entstehen, wodurch das Gerät dann nicht mehr bootet (hence brick), aber auch irgendwo dazwischen auf dem Chip, weiter hinten sozusagen. Dann merkt man das erst, wenn man zb versucht das Teil (ICS-> GB) neu zu partitionieren, oder wenn an dieser Stelle eine Datei geschrieben werden soll. Aber das Gerät wirkt erstmal funktionsfähig.
(Es gibt ja einen User, der sich die Partitionierungstabelle so angepasst hat, dass fehlerhafte Sektoren umgangen werden. Dadurch ist dann weniger Speicher da, aber das Gerät geht noch)

Um vorher abzufragen, wie der Gesamtzustand des Chips ist, dh gibt es bad sectors, schaut man, ob man jeden Sektor des Chips lesen kann, oder ob dabei Fehler auftreten.
Wenn ich weiß, das Ding ist bereits am Abkratzen, versuche ich nicht mehr auf GB zu gehen, sondern überlege mir etwas anderes.
Ich kenne dd nicht auf Sourcecode Level, aber entweder es liest, was es lesen soll (und überspringt nichts heimlich, oder tut nur so). Und dann kann es entweder lesen, weil der Sektor funktioniert, oder es gibt einen IO Fehler, weil der Sektor nicht funktioniert.

Dein Posting klingt so, als würde das Lesen mit dd nicht bringen. Aber wieso?

 

[frank_m]

Man sollte die Arbeitsweise von Flash Speicher in Betracht ziehen und dem beschriebenen Fehlerbild gegenüberstellen, wenn man über die Funktion dieses Programms nachdenkt.

Zum einen hat Flash Speicher ein eigenes Defekt Management. Defekte Sektoren werden ausgeblendet und die Firmware der Flashcontroller sorgt von sich aus dafür, dass die nicht benutzt werden bzw. die Daten dieser Sektoren in Sicherheit gebracht werden, bevor es kritisch wird.
Dazu kommt, dass die Flashbereiche nicht gleichmäßig hintereinander beschrieben werden. Damit würden einige Flashbereiche besonders häufig verwendet und andere gar nicht. Flash wird im Waer Leveling Verfahren beschrieben (Wear leveling - Wikipedia, the free encyclopedia), also die Zugriffe werden beim Schreiben auf das Flash zufällig verteilt. Ein Sektor wird nicht aktualisiert, sondern der Inhalt wird woanders hingeschrieben, und der alte Sektor wird als gelöscht markiert. Die Blöcke, die ein dd liest, haben also nichts gemein mit der physikalischen Position, wo sie im Flash liegen. Anders ausgedrückt: Lies dd die Sektoren 1, 2 und 3 des Flashspeichers, dann kann 1 physikalisch irgendwo in der Mitte, 2 am Anfang und 3 am Ende des Speichers liegen.
Alles in allem ist es also mehr als unwahrscheinlich, dass ein dd defekte Sektoren meldet. Wenn dem so ist, hat man ein ernsthaftes Problem - dann geht nämlich schon seit längerer Zeit was Grundsätzliches beim Zugriff auf den Speicher schief.

Führen wir uns nun noch mal das beschriebene Fehlerbild des Brick Bugs vor Augen: Durch die fehlerhafte Implementierung der Firmware eines Flash Controllers wird beim Löschen mittels des MMC_CAP_ERASE die interne Zuordnung dieses Controllers zerstört. Er ist anschließend nicht mehr in der Lage, gewisse Bereiche des Flashspeichers korrekt zu adressieren und zu beschreiben. Das führt dazu, dass die Flash-Kapazität hinterher "kleiner" aussieht. Hier geht es aber tatsächlich um physikalische Bereiche des Speichers, die der Controller nicht mehr adressieren kann - das hat wiederum nichts mit dem logischen Blöcken zu tun, die dd liest. Vor allem: Der Flash an sich ist gar nicht defekt.

Von daher halte ich einen dd Test für die Detektion des Brick Bugs für suboptimal.

 

[ChIeFgLiDeR25]

Hallo,

Ich hatte ja auch mein Note gebricked bekommen, und habe es an die Firma w-support.com gesendet. Heute habe ich mal online nachgeschaut wie es aussieht, und siehe da..... Es wird auf Garantie repariert und werde es Ende der Woche wiederbekommen. Ich kann diese Firma also nur empfehlen

Gesendet von meinem LT15i mit der Android-Hilfe.de App

 

[ILike]

Hallo, ich hab jetzt bestimmt schon 2 Monate son Brick gefährdetest ROM (TheMIDTeam 1.0 ZCLP6) drauf.
Als ich davon erfahren habe, dachte ich ich warte erstmal was ab und gucke was sich so entwickelt.
Jetzt geht mir das ROM aber langsam etwas aufn Senkel...

Ich würde also gerne auf "CriskeloRom ICS Note V7 LQ3 Base No WIPE" gehen. im namen steht zwar "No WIPE",
in der Anleitung steht aber, dass man einen Wipe ausführen muss (beim WIPE kanns zum Brick kommen richtig?)

================================================
Anleitung

From any GB or ICS roms with mobile Odin and FULL ROOT, do :
1. select "open file" and choose "N7000XXLPY_N7000OXALPY_N7000XXLPT_HOME.tar.md5" file Alternativ
Mirror oder Mirror2 danke an Joko90
2. select "kernel" and choose CF kernel LQ2 zip file
3. select "wipe data and cache", then flash Chriskelo v5
================================================

Meine Fragen sind jetzt die Folgenden:

1. Wie hoch ist die gefahr eines Bricks? (ist wahrscheinlich schwer einzuschätzen...vielleicht in Schulnoten?^^)

2. Ich hab hier mal von nem Skript gelesen, was im falle eines Hartbricks, es wohl schafft, unter kleineren oder
größeren Verlussten des Speichers, den Hartbrick rückgängig zu machen. Ich kann den Post aber nicht mehr finden...

Sorry an all die, die sowas hier sehr nervig und ansträngend finden

Grüße und Vielen Dank

 

[cheezusweezel]

Das geht ja viel einfacher/sicherer:

1. über OdinPC zurück auf eine Pre-rooted GB-Firmware
2. einen CF-Root Kernel inkl. CWM-R flashen (über MobileOdin oder Initial-Rootflasher)
3. in CWM-R den Abyss 4.2 oder Franco v10 Kernel flashen
4. in CWM-R 1x Full-Wipe
5. ein beliebiges, aktuelles CustomICS flashen


Von deiner Basis würde ich auf keinen Fall den direkten Weg mit WIPE DATA nehmen !!!

 

[shaft]

Es reicht doch Punkt 1 & 5?
Nach Punkt 1 einfach nen Werksreset und gut.

 

[cheezusweezel]

Minimal 1, 2 und 5 ...

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

 

[shaft]

<klugscheiß>
Nö, 2 ist unnötig. Hardreset nach 1, Mobile Odin drauf und Custom Rom flashen.
</klugscheiß>

 

[cheezusweezel]

Welches CustomROM schwebt Dir da denn vor, was Du mit MOP flashen willst ?

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

 

[shaft]

ääääähhhh...

Mist, ich hatte die ganze Zeit Stock-ROMs im Kopf.
Klar, wenn die Custom ROM als zip gepackt ist, gehts nur über CWM und Punkt 2, stimmt, da hast du recht Sorry.

 

[cheezusweezel]

Nun verstehen wir uns, hehe. Aber 100% falsch lagst Du auch nicht, immerhin gibt es zwei ICS-CustomROMs die im tar-Format vorliegen ...

 

[ILike]

Ok super, ich danke euch.
eine frage noch, liegt dieser Flushbug (mmc bug, wenn ich mich nicht irre) am Rom oder am Kernel?

 

[shaft]

Kernel.

 

[P-Yeah]

Ich hab auf meine Stock 4.0.3 damals Root gemacht indem ich das CWM installiert habe und danach den Speedmod Kernel geflasht habe.
Dann hab ich einfach die CriskeloRom.zip draufgezogen (Externe SD) und Diese Geflasht.
Dann hab ich Wipe Data/Factory Reset, Wipe Cache und Dalvic Cache durchgeführt.
Dann nochmals Criskelo installiert und nochma Wipe Data Factory Reset.
so reicht das doch völlig hin.
habe mittlerweile auf diese Art und Weise mehrere Roms geflasht ohne probleme.
Mein handy ist 2 wochen alt und bekannt für einen BrickBug.

 

[cheezusweezel]

Was/wie soll die Info nun helfen ?

 

[1887er]

Was/wie soll die Info nun helfen ?

Ist doch klar: man kann Criskelo installieren, dann einen FullWipe machen und danach nochmal Criskelo installieren und anschließend nochmal wipen. Wofür auch immer das gut sein mag