Wichtig: Im A21x sind Flash-Chips verbaut, die vom "Brick Bug" betroffen sind

J

jpo234

Fortgeschrittenes Mitglied
39
Hallo alle,
Anfang des Jahres hatten wir die Diskussion, ob das A21x vom "eMMC Brick Bug" betroffen ist. Ausgelöst wurde die Diskussion durch das von mir im Forum erwähnte Tool "Lag Fix". Dieses Tool führt eine Art Defragmentierung des Flash-Speichers durch. Ein paar Teilnehmer hier im Forum hatten "Lag Fix" ausprobiert und damit ihr Tablett in einen unbenutzbaren Zustand versetzt.

Mein Verdacht war von Anfang an, dass es sich dabei um einen den von anderer Hardware bekannten "eMMC Brick Bug" handelt. Das beruhte aber nur auf Indizien und Uwe waren die nicht stichhaltig genug, so dass die Diskussion darüber mehr oder weniger eingeschlafen ist.

Auf der CyanogenMod Wiki Seite "EMMC Bugs" gibt es jetzt eine Liste von bekanntermassen betroffenen Flash-Chips und eine Anleitung zur Identifizierung. Und zumindest in meinem A210 ist ein Teil verbaut, das folgendermassen charakterisiert ist: "device brick".
Hier die Identifizierung:
Code:
root@android:/sys/class/block/mmcblk0/device # pwd
/sys/class/block/mmcblk0/device
root@android:/sys/class/block/mmcblk0/device # cat name
MAG2GA
root@android:/sys/class/block/mmcblk0/device # cat manfid
0x000015
Bitte lest auf der CyanogenMod-Seite nach, was zu MAG2GA steht. Samsung (als Hersteller des betroffenen Flash-Chips) hat einen Kernel-Patch zur Behebung oder zumindest Vermeidung des Problems bereitgestellt: "mmc: core: new discard feature support at Samsung eMMC v4.41+".
 
Zuletzt bearbeitet:
Ich bitte in dem verlinkten Artikel auch folgende Zeilen zu beachten:

CyanogenMod schrieb:
Some Nook HD+s have been reportedly bricking due to a corruption bug in Samsung's EMMC firmware (model MAG2GA) related to TRIM.

The 2012 Nexus 7 has the same EMMC model as the Nook HD+s (as does the Epic 4G). The Nook HD+ firmware (v06 dated 08/2012) is newer than the 2012 Nexus 7 firmware (v05 05/2012), and yet the Nexus 7s did not seem to have the problem.

Das sagt, dass die Nexus 7 Geräte mit eMMC Firmware 05 (FW-Datum 05/2012) nicht betroffen scheinen.

Ein Check der Firmware-Version bei einem Acer mit Samsung MAG2GA

Code:
# cd /sys/class/block/mmcblk0/device
# cat cid | cut -b 19,20
05

zeigt, dass das Gerät die Firmware-Version 05 hat, die auch im Nexus 7 verbaut ist.

Interessant ist auch das Firmware-Datum:

Code:
# cat date
12/2012

Während die betroffenen Geräte (Nook HD+) Firmware 06 von 08/2012 haben, und die Nexus 7 (2012) die Version 05 von 05/2012 haben, ist Samsung in 12/2012 wieder zur Version 05 zurück gekehrt (Warum wohl?)

Es wird zwar auf einen Code-Änderung von Samsung im Nexus-Kernel hingewiesen (als 'Patch' von Samsung bezeichnet), aber der Kommentar des Patches ließt sich für mich nicht nach Bugfix, sondern nach neuem Feature:

Samsung schrieb:
mmc: core: new discard feature support at Samsung eMMC v4.41+.

Support discard feature if MID field in the CID register is 0x15, EXT.CSD[192]
(device version) is 5 and Bit 0 in the EXT.CSD[64] is 1. Also removed REQ_SECURE flag
check to avoid kernel hang.

This patch is released from samsung.

Das klingt für mich nicht nach Fix für einen Brik-Bug...

MfG Uwe
 
Zuletzt bearbeitet von einem Moderator:
u.k-f schrieb:
Das sagt, dass die Nexus 7 Geräte mit eMMC Firmware 05 (FW-Datum 05/2012) nicht betroffen scheinen.

Ich habe das so gelesen, dass das N7 nicht betroffen ist, weil dort im Kernel der erwähnte Samsung-Patch integriert ist.

Weiter oben in der Tabelle mit den betroffenen Chips steht bei der betroffenen Firmware-Version "all(?)".

Hier die Info zum MAG2GA aus der Tabelle:

EMMC Model ("name") : MAG2GA
manfid: 0x15 (Samsung)
fwrev: all?
fw date: any
hwrev: all?
Impact: device brick
Details: #MAG2GA TRIM bug
 
Zuletzt bearbeitet:
Was ich davon halte, habe ich bereits oben geschrieben:
u.k-f schrieb:
Interessant ist auch das Firmware-Datum:

Code:
# cat date
12/2012

Während die betroffenen Geräte (Nook HD+) Firmware 06 von 08/2012 haben, und die Nexus 7 (2012) die Version 05 von 05/2012 haben, ist Samsung in 12/2012 wieder zur Version 05 zurück gekehrt (Warum wohl?)

u.k-f schrieb:
...aber der Kommentar des Patches ließt sich für mich nicht nach Bugfix, sondern nach neuem Feature:

MfG Uwe
 
Mal rein hypothetisch gesprochen: Angenommen ich würde auf Deine Bedenken eingehen wollen, was stellst Du Dir vor, was man machen sollte?

Die Änderungen von Samsung kann man nicht 1 zu 1 übernehmen, denn der Acer-Kernel hat einen anderen eMMC Treiber als der Nexus-7 Kernel.

Wenn man nun den Treiber vom Nexus 7 in den Acer-Kernel übernehmen würde, wer würde diese schon testen wollen? Und selbst wenn einer von uns es testen würde, würde der andere es glauben wollen?

Also, was denkst Du, wie es weiter gehen sollte?

MfG Uwe
 
Das mit dem anderen eMMC-Treiber war mir nicht bewusst und ist in der Tat ein Hindernis.
CyanogenMod verwendet einen eigenen Tegra-Kernel, der ja z.B. im A700 verwendet wird. Ist dort ein Fix eingebaut?
Wenn nein, sollte man das Problem auf xda vorbringen und mal sehen, ob die dortigen Hardware-Gurus Vorschläge haben. Abhängig von dem was dabei herauskommt weiter nachdenken.

Hast Du im CM10.2 das TRIM aktiviert?
 
Zuletzt bearbeitet von einem Moderator:
Auch der Cyanogen-Kernel ist nicht mit dem Acer-picasso_e2 Kernel vergleichbar (Jede Menge Erweiterungen von Acer, sieht man an den vielen ifdefined CONFIG_MACH_PICASSO_E2)

An sinnvolle Antworten von XDA glaube ich nicht, ich habe schon lange aufgehört, dort Fragen zu stellen, da es dort keinen Acer A210 Bereich gibt, und im Allgemeinen Bereich gehen Geräte-Spezifische Fragen unter. Wenn Du daran glaubst, frage gerne nach, wenn Du was brauchbares raus findest, können wir darüber diskutieren...

MfG Uwe
 
u.k-f schrieb:
Wenn Du daran glaubst, frage gerne nach, wenn Du was brauchbares raus findest, können wir darüber diskutieren...

MfG Uwe

Ich habe eine Frage im XDA A510/700er Forum gepostet:
[Q] A210 and MAG2GA TRIM bug, A510/700 affected, too? - xda-developers

Der ursprüngliche Beitrag von 14:52 Uhr wurde um 15:00 Uhr ergänzt:

Nur zur Info: Auch das A700 scheint von dem Problem betroffen zu sein. Pawtip, der Cyanogen-Entwickler des A700 schreibt: "FStrim will have no effect on our device since I've disabled TRIM support within the kernel, as it is this command that causes bricks on our device. (There is a bug in Samsung's EMMC firmware.)"
 
Ich habe die Sache jetzt selbst in die Hand genommen, und die Änderungen von Samsung in den Acer A21x Kernel integriert:

Code:
--- ../backup/drivers/mmc/card/block.c	2012-11-14 09:12:59.000000000 +0100
+++ drivers/mmc/card/block.c	2013-12-23 01:48:21.918296586 +0100
@@ -707,8 +707,11 @@
 
 	from = blk_rq_pos(req);
 	nr = blk_rq_sectors(req);
-
-	if (mmc_can_trim(card))
+	
+	//Only for Samsung MAG2GA do this
+	if (mmc_can_discard(card))
+		arg = MMC_DISCARD_ARG;
+	else if (mmc_can_trim(card))
 		arg = MMC_TRIM_ARG;
 	else
 		arg = MMC_ERASE_ARG;
@@ -1218,7 +1221,8 @@
 		/* complete ongoing async transfer before issuing discard */
 		if (card->host->areq)
 			mmc_blk_issue_rw_rq(mq, NULL);
-		if (req->cmd_flags & REQ_SECURE)
+		//Standard, but do this not for Samsung MAG2GA
+		if ((req->cmd_flags & REQ_SECURE) && !mmc_can_discard(card))
 			ret = mmc_blk_issue_secdiscard_rq(mq, req);
 		else
 			ret = mmc_blk_issue_discard_rq(mq, req);
diff -ru ../backup/drivers/mmc/card/queue.c drivers/mmc/card/queue.c
--- ../backup/drivers/mmc/card/queue.c	2012-11-14 09:12:59.000000000 +0100
+++ drivers/mmc/card/queue.c	2013-12-23 01:45:07.712738080 +0100
@@ -140,7 +140,8 @@
 
 	queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, q);
 	q->limits.max_discard_sectors = max_discard;
-	if (card->erased_byte == 0)
+	//Standard, but do this not for Samsung MAG2GA
+	if (card->erased_byte == 0  && !mmc_can_discard(card))
 		q->limits.discard_zeroes_data = 1;
 	q->limits.discard_granularity = card->pref_erase << 9;
 	/* granularity must not be greater than max. discard */
diff -ru ../backup/drivers/mmc/core/core.c drivers/mmc/core/core.c
--- ../backup/drivers/mmc/core/core.c	2012-11-14 09:12:59.000000000 +0100
+++ drivers/mmc/core/core.c	2013-12-23 01:40:41.560084072 +0100
@@ -1581,8 +1581,15 @@
 				          unsigned int arg, unsigned int qty)
 {
 	unsigned int erase_timeout;
-
-	if (card->ext_csd.erase_group_def & 1) {
+	
+	//if DISCARD_ARG (only on MAG2GA) or manfid == Samsung 
+	if (arg == MMC_DISCARD_ARG ||
+		(arg == MMC_TRIM_ARG && 
+		card->cid.manfid == 0x15 && 
+		card->ext_csd.rev >= 6)
+	) {
+		erase_timeout = card->ext_csd.trim_timeout;
+	} else if (card->ext_csd.erase_group_def & 1) {
 		/* High Capacity Erase Group Size uses HC timeouts */
 		if (arg == MMC_TRIM_ARG)
 			erase_timeout = card->ext_csd.trim_timeout;
@@ -1858,6 +1865,15 @@
 }
 EXPORT_SYMBOL(mmc_can_trim);
 
+//Only Samsung MAG2GA has MMC_DISCARD_FEATURE
+int mmc_can_discard(struct mmc_card *card)
+{
+	if (card->ext_csd.feature_support & MMC_DISCARD_FEATURE)
+		return 1;
+	return 0;
+}
+EXPORT_SYMBOL(mmc_can_discard);
+
 int mmc_can_secure_erase_trim(struct mmc_card *card)
 {
 	if (card->ext_csd.sec_feature_support & EXT_CSD_SEC_ER_EN)
diff -ru ../backup/drivers/mmc/core/mmc.c drivers/mmc/core/mmc.c
--- ../backup/drivers/mmc/core/mmc.c	2012-11-14 09:12:59.000000000 +0100
+++ drivers/mmc/core/mmc.c	2013-12-23 03:09:49.724848534 +0100
@@ -458,6 +458,17 @@
 		card->erased_byte = 0xFF;
 	else
 		card->erased_byte = 0x0;
+		
+	//Set DISCARD_FEATURE only for Samsung MAG2GA
+	if ((card->cid.manfid == 0x15) && (ext_csd[64] & 0x01))
+	{
+		card->ext_csd.feature_support |= MMC_DISCARD_FEATURE;
+		pr_warning ("Samsung eMMC Chip detected > use MMC_DISCARD_FEATURE");
+	}
+	else
+	{
+		pr_warning ("None Samsung eMMC Chip detected");
+	}
 
 #if defined(CONFIG_ARCH_ACER_T30)
 	erase_group_def = ext_csd[EXT_CSD_ERASE_GROUP_DEF];

Kurze Erklärung:

Wenn festgestellt wird, dass es sich um ein Gerät mit MAG2GA handelt, wird die Funktion mmc_can_discard(...) true zrück liefern. Diese wird im weiteren verwendet, um zu entscheiden, ob es sich um ein Gerät mit oder ohne MAG2GA handelt.

Wenn bei diesem Gerät ein Request für einen 'Secure-Discard' (die laut Samsung vom Bug betroffene Funktion) aufgerufen werden soll, wird statt dessen ein 'Normaler Discard' aufgerufen.

Wir bei einem Gerät mit MAG2GA ein 'Normaler Discard' aufgerufen, wird statt des 'Standard-TRIM' ein TRIM mit veränderten Parametern (Wie sie Samsung auf im Nexus-Kernel verwendet) aufgerufen.

Bei Geräten ohne MAG2GA bleibt alles beim alten.

Zusätzlich habe ich Debug eingebaut, die angeben, welcher eMMC Chip gefunden wurde.

Ich bitte um Meinungen dazu.

MfG Uwe
 
Zuletzt bearbeitet von einem Moderator:
  • Danke
Reaktionen: Chefingenieur
Standard diff ist schwer zu lesen. Kannst du das als unified posten?
 
Habe dazu kein Tool zur Hand, würden die veränderten Dateien helfen, die kann mit den original Acer Sourcen diffen...

MfG Uwe
 
diff -u anstelle von einfach nur diff.
 
kommt nacher.

Ich war wohl blind, hatte unter diff --help nichts gefunden:blushing:

MfG Uwe
 
Ich habe mir jetzt einen alten A210 besorgt, der einen defekt im Akku/Ladestromregler hat und daher nur noch zum Basteln geeignet ist, aber der einen MAG2GA drin hat:

Code:
root@android:/sys/class/block/mmcblk0/device # cat name
cat name
MAG2GA
root@android:/sys/class/block/mmcblk0/device # cat manfid
cat manfid
0x000015
root@android:/sys/class/block/mmcblk0/device # cat cid | cut -b 19,20
cat cid | cut -b 19,20
05
root@android:/sys/class/block/mmcblk0/device # cat date
cat date
06/2012

Also das ideale Testgerät, um mal ordentlich (mit dem o.a. Kernel-Patch) TRIM zu testen.

Ich habe noch keine genaue Idee, wie ich so einen Test durchführe, und wäre daher für Code-Vorschläge / Links dankbar, bei denen ich sicher sein kann, dass tatsächlich TRIM aufgerufen wurde.

MfG Uwe
 
u.k-f schrieb:
Ich habe noch keine genaue Idee, wie ich so einen Test durchführe, und wäre daher für Code-Vorschläge / Links dankbar, bei denen ich sicher sein kann, dass tatsächlich TRIM aufgerufen wurde.

Die kanonischen Quellen sind hier: fstrim.c

Dieses Programm wurde auch vom mittlerweile berüchtigten LagFix aufgerufen.

Wichtig: Auf meine Frage im korrespondierenden XDA-Thread hat Pawtip geschrieben: "The bug will slowly break the eMMC which leads to freeze when the problematic block is read. Wiping caused a lot of brick because the entire partition is TRIMed. E.g. If the bug is present, enabling TRIM for files may not brick it right away, but may brick it one year later.". Das dürfte sich auf die ext4-mount-Option "-o discard" beziehen, die bei jedem freiwerdenden Block ein TRIM auslöst.
 
Zuletzt bearbeitet:

Ähnliche Themen

An-Dro-Id
Antworten
6
Aufrufe
4.332
DAC324
D
Kiwi++Soft
Antworten
41
Aufrufe
34.081
Ladylike871
Ladylike871
Kiwi++Soft
Antworten
13
Aufrufe
3.876
Kiwi++Soft
Kiwi++Soft
Zurück
Oben Unten