EMMC BrickBug und die custom kernel

[jpo234]

Hallo alle,
durch die leidigen Erfahrungen mit dem LagFix besteht ja der dringende Verdacht, dass das A210 für den EMMC BrickBug anfällig ist. Der Workaround dürfte sein, die MMC_CAP_ERASE nicht zu setzen.
Ist dieser Fix in den Kernelversionen eingebaut, die hier im Forum herumgereicht werden?

P.S.: Quelle https://github.com/AOKP/system_extras/commit/60c5383fd093826fb3f95f3dda4f313aa54f4f69

 

[W!ldGunM@n]

Ich denke eher nicht... aber danke für den Hinweis...

 

[jpo234]

Die benötigte Änderung findet sich hier:
xda-developers - View Single Post - [BrickBug][Fix][Kernel][01.08]Detection of stock kernel safety + patch guide

Also einfach nicht das Flag in den Capabilities des Controllers setzen.

P.S.: Der Fix sollte auch in die Kernel für das Recovery, also CWM.

Der ursprüngliche Beitrag von 14:38 Uhr wurde um 14:56 Uhr ergänzt:

Die verdächtige Änderung für Tegra-Geräte dürfte das hier sein:
https://android.googlesource.com/kernel/tegra/+/c645ffa8ed7fda502d8a763cf5df3e872a43fbba%5E!/#F0

 

[u.k-f]

Hallo alle,
durch die leidigen Erfahrungen mit dem LagFix besteht ja der dringende Verdacht, dass das A210 für den EMMC BrickBug anfällig ist. Der Workaround dürfte sein, die MMC_CAP_ERASE nicht zu setzen.
Ist dieser Fix in den Kernelversionen eingebaut, die hier im Forum herumgereicht werden?

P.S.: Quelle https://github.com/AOKP/system_extras/commit/60c5383fd093826fb3f95f3dda4f313aa54f4f69

Zunächst mal möchte ich anmerken, dass die von mir verteilten CustomKernel im Bereich des EMMC Handlings keine Unterschiede zu dem Acer Stock-Kernel aufweisen!

Jetzt zu dem Beitrag von jpo234:

Der hier referenzierte Fix geht aber zunächst nicht in den Kernel sondern in libext4_utils.so.

Es wird hier allerdings eine Empfehlung ausgesprochen, statt dieses Fixes einen Fix im Kernel vorzunehmen:

For affected devices with kernel source, MMC_CAP_ERASE should be removed
from the kernel instead.

Die Basis der von mir erstellten Kernel ist der von Acer für das A211 veröffentlichte Sourcecode von November 2112. Ich weiss nicht genau, von welchem GIT-HUB Acer wiederum seine Sourcen hat, will sagen, ob die entsprechenden Änderungen in die Acer-Sourcen eingeflossen sind.

Ich werde mal prüfen, was sich in den Acer-Sourcen (und smit meinen Sourcen) dazu findet. Die habe ich allerdings nur zuhause... (Also bitte nicht so schnell mit einer qualifizierten weil auf Basis der Sourcen überprüften Antwort rechnen.)

Insgesammt möchte ich noch den Hinweis geben, dass selbst wenn ich feststellen sollte, dass das MMC_CAP_ERASE Flag gestezt wird, ich nicht sofort einen Kernel bauen werde, in dem dieses Flag unterdrückt wird.

Bevor ich irgendeine Änderung am Kernel vornehme und veröffentliche, muss ich erst genau verstehen, was es mit diesem Flag auf sich hat. Ich bitte dafür um Verständnis.

Interessant ist auch, das die hier referenzierten Dokumente sich wiedersprechen:

In dem Beitrag von xda-developers wird empfohlen, das setzen des Flags zu unterdrücken:

So you mean, to solve the problem we need to change
mmc->caps |= MMC_CAP_SDIO_IRQ | MMC_CAP_ERASE;
to
mmc->caps |= MMC_CAP_SDIO_IRQ;

während hier in den Github-Sourcen das Flag explizit dazugesetzt wird (siehe grüne Zeile):

diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 341487c..bf9da0f 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c

@@ -265,6 +265,7 @@
 	pltfm_host->priv = tegra_host;
 	tegra_host->clk_enabled = true;
 
[COLOR="Lime"]+	host->mmc->caps |= MMC_CAP_ERASE;[/COLOR]
 	if (plat->is_8bit)
 		host->mmc->caps |= MMC_CAP_8_BIT_DATA;

Also, bevor hier jetzt in blinden Aktionismus ausgeartet wird, sollte erst mal ordentlich Recherche betrieben werden.

Grüsse Uwe

 

[jpo234]

Der hier referenzierte Fix geht aber zunächst nicht in den Kernel sondern in libext4_utils.so.

Es wird hier allerdings eine Empfehlung ausgesprochen, statt dieses Fixes einen Fix im Kernel vorzunehmen:

For affected devices with kernel source, MMC_CAP_ERASE should be removed
from the kernel instead.

Richtig. Auf den Kernel-Kommentar hatte ich mich bezogen...

Interessant ist auch, das die hier referenzierten Dokumente sich wiedersprechen:

In dem Beitrag von xda-developers wird empfohlen, das setzen des Flags zu unterdrücken:


während hier in den Github-Sourcen das Flag explizit dazugesetzt wird (siehe grüne Zeile):

Nicht wirklich. Der xda-Thread beschreibt den Fix für die Samsung-Controller und der GitHub-Diff zeigt den Patch, mit dem das Problem potentiell in den Tegra-Kernel gewandert ist. Meine Wortwahl "fragliche Änderung" ist etwas unglücklich, "verdächtig" wäre richtiger.

Bezüglich Recherche:
http://lxr.linux.no/linux+*/include/linux/mmc/host.h#L226

Das Flag zeigt an, dass der fragliche Flash-Controller das trim-Kommando unterstützt. Dieses Flag auszuschalten sollte eine harmlose Änderung sein. Interessant wird dann der Test: Wenn LagFix wirklich über den EMMC BrickBug gestolpert ist, sollte es danach zumindest keinen Schaden mehr anrichten. Freiwillige vor, das auszuprobieren!

 

[u.k-f]

Nicht wirklich. Der xda-Thread beschreibt den Fix für die Samsung-Controller und der GitHub-Diff zeigt den Patch, mit dem das Problem potentiell in den Tegra-Kernel gewandert ist. Meine Wortwahl "fragliche Änderung" ist etwas unglücklich, "verdächtig" wäre richtiger.

Stimmt, das hätte ich bei zweimaligem lesen Deines Textes merken müssen...mea culpa :blushing:

Trotzdem gehe ich davon aus, dass das Setzen dieses Flags auch einen bestimmten Sinn hat (Sonst hätte man es ja nicht erst eingebaut). Daher werde ich jetzt sicher nicht das Flag einfach so rauswerfen, ohne verstanden zu haben, was die 'Für' und die 'Wieder' der Geschichte sind...

Grüsse Uwe

Der ursprüngliche Beitrag von 15:51 Uhr wurde um 15:59 Uhr ergänzt:

Bezüglich Recherche:
LXR linux/include/linux/mmc/host.h

Das Flag zeigt an, dass der fragliche Flash-Controller das trim-Kommando unterstützt. Dieses Flag auszuschalten sollte eine harmlose Änderung sein. Interessant wird dann der Test: Wenn LagFix wirklich über den EMMC BrickBug gestolpert ist, sollte es danach zumindest keinen Schaden mehr anrichten. Freiwillige vor, das auszuprobieren!

Ich baue Dir gerne einen Kernel ohne dieses Flag aber testen musst Du es. Nur dürfte der Test auf Deinem A210 keinen Sinn machen, da LagFix bei Deinem Gerät auch ohne Patch keinen Schaden angerichtet hat... Und diese Version dürfte auch nicht verteilt werden...(Habe da schlechte Erfahrungen gemacht mit Leuten, die Kernel aus Debug-Sessions nachher weiterverteilen...)

Aber insgesammt sehe ich die Sache etwas nachdenklich.Das trim-Kommando hat ja auch seinen Sinn, sonst wäre LagFix ja nicht nötig gewesen. Also einfach das Flag löschen...hhhhmmmm...

Ich denke darüber nach...

Grüsse Uwe

Der ursprüngliche Beitrag von 15:59 Uhr wurde um 17:25 Uhr ergänzt:

...Das Flag zeigt an, dass der fragliche Flash-Controller das trim-Kommando unterstützt. Dieses Flag auszuschalten sollte eine harmlose Änderung sein....

Sorry, auf dieser Aussage muss ich leider nochmals rumreiten.

Ich halte das Auschalten des Flag nicht für eine harmlose Änderung Ich gehe sogar davon aus, dass es eine ebenfalls hardware-gefährtende Änderung ist.

Hintergund:

Die Daten in einem NAND können zwar in 4kb Daten-Paketen (Page genannt) geschrieben werden, aber nur in 256 kb Paketen (Block genannt) gelöscht. Mit dem TRIM Kommand kann dem NAND-Speicher mitteilen, dass ein 256 kb Block nicht mehr benötigt wird und er im ganzen gelöscht werden kann.

Soll der Block nun neu beschrieben werden, und er wurde vorher gelöscht, werden die Daten darauf einmal geschrieben. Damit wurde der Block einmal gelöscht und einmal beschrieben. Das wars.

Ohne das TRIM Kommando passiert folgendes: Soll ein Block neu beschrieben werden so geschieht das Pageweise. Mit jeder Page die geschrieben wird, wird festgestellt, dass die restlichen Pages (derer 63) nicht leer sind. Dann werden diese in den Cache geladen, der ganze Block gelöscht, die gecachten Pages zurück geschrieben und die neu zu schreibende Page wird auch geschrieben. Diesen Prozess nennt man 'WriteAmplification'.

Das kostet nicht nur Performance und damit Zeit, sondern auch Lebensdauer, da im Zweifelsfall der NAND 63 mal unnötig gelösct wird. Das heisst, dass der NAND Speicher nur ein 64.tel seiner Lebensdauer hätte. Da die Lebensdauer von Flash-Speicher nur bei etwa 10000 mal löschen liegt, halte ich das für eine signifikante Verringerung der Lebensdauer des NAND Speichers. (Quellen TRIM WriteAmplification

Ich bitte daher um eine eingehende Diskussion dieses Themas

Grüsse Uwe

 

[jpo234]

Das "harmlos" bezog sich darauf, dass das System nicht sofort gebrickt wird. Was mich veranlasst hat, diesen Thread auszumachen, waren Berichte, dass eventuell auch ein Wipe aus dem Recovery den Bug auslösen kann.
Des Weiteren ist das von Dir beschriebene Verhalten im Moment der Standard. Das ext4 Filesystem sendet das TRIM Kommando nur, wenn die mount - Option "discard" verwendet wird. Meines Wissens nach ist das auf dem A210 im Moment nicht der Fall (Bitte korrigieren!)

Gesendet von meinem A210 mit Tapatalk 2

 

[vetzki]

Rausnehmen oder nicht? (zumindest aus dem recovery?). Kann ich gerne machen...

Gesendet von meinem Nexus 4 mit der Android-Hilfe.de App

 

[W!ldGunM@n]

... und ich erkläre mich gerne als Tester bereit...

 

[u.k-f]

Das "harmlos" bezog sich darauf, dass das System nicht sofort gebrickt wird. Was mich veranlasst hat, diesen Thread auszumachen, waren Berichte, dass eventuell auch ein Wipe aus dem Recovery den Bug auslösen kann.

Mit dem Attribut harmlos sollte man immer so, umgehen, dass unmissverständlich klar ist, was evtl ungefährlich ist und was nicht.

Des Weiteren ist das von Dir beschriebene Verhalten im Moment der Standard. Das ext4 Filesystem sendet das TRIM Kommando nur, wenn die mount - Option "discard" verwendet wird. Meines Wissens nach ist das auf dem A210 im Moment nicht der Fall (Bitte korrigieren!)

Gesendet von meinem A210 mit Tapatalk 2

Rausnehmen oder nicht? (zumindest aus dem recovery?). Kann ich gerne machen...

Gesendet von meinem Nexus 4 mit der Android-Hilfe.de App

... und ich erkläre mich gerne als Tester bereit...

Sollte man nicht vielleicht erst mal sich alle betreffenden Stellen im Source-Code angucken um genau zu wissen, was für Risiken und Nebenwirkungen man eingeht? Ich sage ja nicht, dass man es nicht tun sollte, sondern nur 'Erst informieren, dann reagieren'... Und niemals postulieren...

War doch schon beim LagFix so, einer postet was, alle anderen machen es ungeprüft nach, dann rappelt es und hinterher ist man schlauer.

Ich habe den LagFix-Thread auch gelesen, fing an mir die o.a. Artikel in Wikipedia reinzuziehen, und während ich noch am abwägen war, kamen auch schon die ersten Problem-Meldungen.

Wenn MMC_CAP_ERASE ohne die Option "discard" wirkungslos ist und nicht mit "discard" gemountet wird, besteht ja auch kein akuter Handlungsbedarf, und wenn es anders wäre, sollte man sich seiner Handlungen sicher sein.

Grüsse Uwe

 

[W!ldGunM@n]

Wer nicht wagt, der nicht gewinnt... mir egal obs in die Brüche geht... kanns ja dann zu acer einsenden ;-)

 

[u.k-f]

Wer nicht wagt, der nicht gewinnt... mir egal obs in die Brüche geht... kanns ja dann zu acer einsenden ;-)

Nur innerhalb der Garantiezeit! Wenn (ich sage wenn, nicht dass!!) Du die Lebensdauer Deines NAND runterziehst, dann verreckts vielleicht genau pünktlich nach Ablauf der Garantiezeit. Ich gehe ja auch nicht davon aus, dass es zu einer sofortigen Katastrofe kommt, sondern nur, dass es nicht ausgeschlossen ist. dass es zu einem verstärkten Verschleiss kommt.

Also warte doch einfach mal ab, was bei gründlicher Recherche rauskommt.

BTW Dir rechne ich aber hoch an, dass Du die Warnung vor dem LagFix gepostet hast, die IMHO in den ersten Post gehört hätte...

Grüsse Uwe

 

[W!ldGunM@n]

Naja... meist habe ich die Geräte nicht mal bis die Garantie abgelaufen ist... ich bin nen Freak und muss immer das Neuste haben... von da her

 

[jpo234]

.

Wenn MMC_CAP_ERASE ohne die Option "discard" wirkungslos ist und nicht mit "discard" gemountet wird, besteht ja auch kein akuter Handlungsbedarf, und wenn es anders wäre, sollte man sich seiner Handlungen sicher sein.

Grüsse Uwe

Den potentiellen Handlungsbedarf gibt es beim recovery. Die ext4-Tools können bei einem Wipe den trim-system Call aufrufen und dann den Flash zerschießen. Darauf bezog sich der Patch aus dem ersten Post.

Gesendet von meinem A210 mit Tapatalk 2

 

[u.k-f]

Den potentiellen Handlungsbedarf gibt es beim recovery. Die ext4-Tools können bei einem Wipe den trim-system Call aufrufen und dann den Flash zerschießen. Darauf bezog sich der Patch aus dem ersten Post.

Gesendet von meinem A210 mit Tapatalk 2

Dann ist der Titel des Threads nicht ganz angemessen. Müsste dann besser heissen EMMC BrickBug und das CWM-Recovery, oder?

Gibt es den inzwischen irgendeine verlässliche Quelle, dass es bei dem LagFix Problem sich tatsächlich um irgendwas mit dem EMMC BrickBug handelt, oder hat vielleicht das LagFix-Tool einfach nur die Bits von der Bootloader-Partition mal kräftig durchgemischt?

Nach meinem Verständnis des Brick-Bugs (aber ich habe mich noch nicht wirklich damit beschäftigt!!!) brät der ja nur die Blöcke durch, auf denen er rumschreibt. Wenn das so wäre wieso kommt das Tablet nicht mehr in den Bootloader Modus? Dann müsste LagFix auch auf der Bootloader Partion rumgebraten haben. Was soll aber dort gemacht werden, so oft wird ja wohl nicht der Bootloader geupdated, dass es sich lohnt, dort irgenwas zu fixen.
Also, wenn es dort nicht zu fixen gibt, hat sich das Tool wohl verirrt, und wenn es das getan hat, wer schliesst dann aus, dass es buggy ist. Wenn es aber buggy ist, war es vielleicht kein Brick-Bug sonder schlicht und Ergreifend ein 'DreckFix' statt einem LagFix

Aber jetzt mal wieder zurück zu den harten Fakten:

Ich habe mal angefangen das zu tun, was zu tun ist, wenn man überlegt, am Kernel rumzuschrauben: Ich lese Sourcen.

Und wieder fällt mir eines auf, die Acer-Sourcen weichen sehr stark von denen ab, die sonst so (auf Github, bei CyanogenMod) im Internet zu finden sind (wobei ich immer wieder zu den Eindruck habe, dass die Acer-Sourcen weiter entwickelt sind, aber das ist nur meine persönliche Meinung).

Ja, es gibt auch in den Acer-Sourcen das MMC_CAP_ERASE Flag und es wird dort auch gesetzt. Welche Schlüsse ich jedoch daraus ziehe mache ich ganz sicher nicht auf Grund dessen fest, was Leute sagen, die sich ganz andere Sourcen angeguckt haben, als die Acer Sourcen.

Bis ich mir eine Meinung bilden kann, dauert es noch eine Weile. Ich fordere aber jeden der C lesen kann dazu auf, selbst mal in die Sourcen reinzugucken, denn 4 oder 6 oder 8 Augen sehen mehr als zwei.

Grüsse Uwe

 

[jpo234]

Bis ich mir eine Meinung bilden kann, dauert es noch eine Weile. Ich fordere aber jeden der C lesen kann dazu auf, selbst mal in die Sourcen reinzugucken, denn 4 oder 6 oder 8 Augen sehen mehr als zwei.

Das Problem ist, dass Sourcecode lesen nicht hilft, wenn die eigentliche Ursache im Flash Controller oder dessen Firmware liegt (siehe z. B. das aktuelle Samsung UEFI Problem). Was man da braucht, ist eher ein Hardwarelabor wo man die Interaktion zwischen dem Host und dem Controller verfolgen kann.
Aus meiner Sicht ist die Lage recht einfach: TRIM auszuschalten ändert am aktuellen System nichts, verhindert aber, dass unbedarfte Applikationen a'la LagFix potentiell das Tab bricken.


Gesendet von meinem A210 mit Tapatalk 2

 

[u.k-f]

...Die ext4-Tools können bei einem Wipe den trim-system Call aufrufen und dann den Flash zerschießen....

Bitte welchen System-Call eigentlich? Wäre interessant, sich dann mal anzugucken, was dort passiert, nur ich finden den von Dir benannten System-Call leider nicht.

Anbei eine Liste, welche SystemCalls es im Acer-Kernel gibt. Bitte nicht erschrecken, die letzten 4 (kiwi_get_cpu...) sind von mir.

Grüsse Uwe

 

[u.k-f]

Das Problem ist, dass Sourcecode lesen nicht hilft, wenn die eigentliche Ursache im Flash Controller oder dessen Firmware liegt (siehe z. B. das aktuelle Samsung UEFI Problem). Was man da braucht, ist eher ein Hardwarelabor wo man die Interaktion zwischen dem Host und dem Controller verfolgen kann.
Aus meiner Sicht ist die Lage recht einfach: TRIM auszuschalten ändert am aktuellen System nichts, verhindert aber, dass unbedarfte Applikationen a'la LagFix potentiell das Tab bricken.


Gesendet von meinem A210 mit Tapatalk 2

Nochmals, woher nimmst Du die Gewissheit, dass es sich überhaupt um einen EMMC Bug handelt?

Und noch vielmehr interessiert mich die Frage woher Du die Gewissheit nimmst, dass das am aktuellen System nichts ändert. Wieso sollte man eine Flag einbauen und das Filesystem so implementieren, dass es diese Option nur nutzt, wenn die Option 'discard' gestzt ist, aber dann die Option 'discard' nicht im Mount Befehl nutzen?

Also, bevor ich mich darauf verlasse, dass es im System nichts ändert, gucke ich mir den Source Code an

Grüsse Uwe

 

[jpo234]

Bitte welchen System-Call eigentlich? Wäre interessant, sich dann mal anzugucken, was dort passiert, nur ich finden den von Dir benannten System-Call leider nicht.

Anbei eine Liste, welche SystemCalls es im Acer-Kernel gibt. Bitte nicht erschrecken, die letzten 4 (kiwi_get_cpu...) sind von mir.

Grüsse Uwe

What does LagFix do?
It calls fstrim utility, which calls ioctl operation called TRIM, TRIM does the magic.

Der fragliche Systemcall ist also ein ioctl. Aus fstrim.c:

 * This program uses FITRIM ioctl to discard parts or the whole filesystem
 * online (mounted). You can specify range (start and length) to be
 * discarded, or simply discard whole filesystem.

    if (ioctl(fd, FITRIM, &range))
        err(EXIT_FAILURE, _("%s: FITRIM ioctl failed"), path);

Der ursprüngliche Beitrag von 22:55 Uhr wurde um 23:01 Uhr ergänzt:

Nochmals, woher nimmst Du die Gewissheit, dass es sich überhaupt um einen EMMC Bug handelt?

Die Gewissheit habe ich nicht. Wenn Du meine Posts liest, wirst Du feststellen, dass ich immer von der potentiellen Gefahr spreche.

Und noch vielmehr interessiert mich die Frage woher Du die Gewissheit nimmst, dass das am aktuellen System nichts ändert. Wieso sollte man eine Flag einbauen und das Filesystem so implementieren, dass es diese Option nur nutzt, wenn die Option 'discard' gestzt ist, aber dann die Option 'discard' nicht im Mount Befehl nutzen?

Also, bevor ich mich darauf verlasse, dass es im System nichts ändert, gucke ich mir den Source Code an

Grüsse Uwe

Gewissheiten habe ich hier auch keine. Wenn es aber Berichte gibt, dass auf Samsung-Geräten das Stock-Recovery den BrickBug ausgelöst hat, würde ich eben gern auf Nummer sicher gehen.

 

[u.k-f]

... trim-system Call...

...ioctl(fd, FITRIM, &range)...

Eine etwas präziesere Ausdrucksweise würde es mir erleichtern, nachzuvollziehen, von was Du sprichst...

Danke im voraus...

Grüsse Uwe