EMMC BrickBug und die custom kernel

[jpo234]

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

Danke im voraus...

Grüsse Uwe

ioctl ist ein Systemcall, oder?

Ein Paar sehr interessante Folien zum Thema gibt es unter
http://people.redhat.com/lczerner/d...of_Linux_DIscard_support_Dev_Con2011_Brno.pdf

Besonders interessant:
Seite 20:

mount -o discard /dev/sdc /mnt/test

Seite 30:

 mkfs.ext4 -E discard /dev/sdc

=> hier ist die Gefahr aus dem Recovery!

 

[u.k-f]

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.

Und genau darum geht es. Ich halte die vorgeschlagene Änderung genauso für eine potentielle Gefahr. Und daher werde ich erst mal keine Änderung vornehmen, bis ich mir über die Konsequenzen dieser Änderung im klaren bin.

Zumal die Quellen wenig bis garnichts mit dem Acer-Kernel zu tun haben:

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

Der referenziert Change war z.B. ein Linux 2.6.x Kernel

Wer mag, kann sich ja gerne einen Kernel mit den vorgeschlagenen Änderungen bauen, ich tue das nicht, bevor ich Klarheit habe...

ioctl ist ein Systemcall, oder?

aber nicht der TRIM-System-Call (siehe erstes Zitat von Dir). Erst von Äpfeln reden und dann Birnen meinen...

Custom-Kernel schreiben und CWM meinen...

Auf einen Change im 2.6.x Kernel verweisen wenn man über einen 3.1.10 Kernel redet...

Das macht es mir nicht leichter, Deinen Ausführungen, die ich sehr ernst nehme und bedenkenswürdig finde, zu folgen. Das war auch nicht als Provokation gemeint, sondern eine ernste Bitte an Dich...

Grüsse Uwe

 

[jpo234]

Custom-Kernel schreiben und CWM meinen...

Na ja Custom-Kernel stimmt schon. Nur eben vor allem der Kernel im Recovery, weil das im Normalbetrieb die riskante Operation durchführen kann.

P.S.: Ich habe Post 21 um Referenzen zum Hintergrund von discard/TRIM ergänzt...

 

[u.k-f]

Das Problem ist jetzt etwa das folgende:

• Du befürchtest Gefahr durch das Zulassen von TRIM.
• Ich befürchte Gefahr durch das Weglassen von TRIM.
• Beides kann man nicht haben.

Ginge es um einen normalen Kernel (Nicht den vom CWM) könnte ich anbieten, das TRIM ein/ausschaltbar zu machen (so wie auch das OC)

Im CWM hat man nicht ganz so viele Möglichkeiten. Ich stimme mich mal mit Vetzki ab, welche Möglichkeiten es gibt, dem User die Wahl zu lassen, ob er mit oder ohne TRIM operieren will.

Grüsse Uwe

Der ursprüngliche Beitrag von 23:34 Uhr wurde um 23:40 Uhr ergänzt:

Eine kleine Anmerkung fehlt natürlich noch:

Könnten Sie bitte Ihr kleines Gezänk vorsetzen, ich fand es sehr aufschlussreich

 

[Chefingenieur]

Hallo Uwe,

ich kann zu der Sache leider nicht viel beitragen da meine C Kenntnisse sehr beschränkt sind, ich würde es gerade noch schaffen eine LED auf einem 8051er blinken zu lassen
Ich möchte nur dass du weißt dass ich es super finde wie du dich der Sache näherst und nicht einfach "vorsichtshalber" irgendwas änderst.

 

[jpo234]

Ich möchte das Thema nochmal etwas anschubsen. Im ersten Post zu diesem Thread hatte ich auf einen AOKP-Patch verwiesen, in dem das TRIM für die ext4_utils im Recovery deaktiviert wurde.
Die gleiche Gefahr sehe ich auch beim A210. Zugegebenermaßen beruht meine Befürchtung auf der Annahme, dass die Probleme mit dem LagFix tatsächlich auf das TRIM zurückzuführen sind. Dafür gibt es bisher nur Indizien, aber keine wirklichen Beweise. Diese werden wir aber wohl nur schwer bekommen, da Experimente (vor allem "erfolgreiche") immer das Tab riskieren.
Die entsprechende Operation im Kernel zumindest für das Recovery zu deaktivieren ist aus meiner Sicht ungefährlich, da im Falle eines Problems ein neuer Kernel geflasht werden kann.
Und da der TRIM-Befehl nach meinen Kenntnissen der Lage normalerweise nicht ausgeführt wird (Stichwort ext4 "discard" mount Option), sehe ich ehrlich gesagt auch kein Risiko für den normalen Systemkernel. Aber da besteht eben nur bei Programmen wie LagFix ein Risiko, so dass da kein akuter Handlungsbedarf besteht.
Dass bis jetzt beim Flashen nichts passiert ist, ist keine Garantie, dass auch zukünftig nichts passieren wird. Merke: An absence of evidence is not evidence of absence!

 

[W!ldGunM@n]

Nach etwas Einlesen in das Thema bin ich zu dem Schluss gekommen, dass ich auf Trim nicht verzichten will, weil für eine ssd tödlich ist... nach einer Weile wird diese nämlich schleppend langsam.
Auch habe ich Lagfix mit dem Bewusstsein der möglichen Zerstörung etliche Male schon ausgeführt, ohne das es mir bzw. meinen Tab geschadet hätte.
Und wenn das Teil wirklich iwann aussteigen sollte... habe ich 2 Jahre Garantie.

 

[jpo234]

Also wenn Du wirklich so mutig bist (und Du ja auch Deine eigenen Kernel baust), dann aktiviere doch mal die discard-Option beim mounten der ext4-Partitionen. Das sollte das TRIM im Hintergrund ausführen, wenn das Filesystem passende Blöcke freigibt.

Was mir aber vor allem Sorge bereitet ist, dass TRIM auch beim Flashen eines neuen ROMs aus CWM aufgerufen werden kann. Damit kann das vermeintlich sichere Update ein Tab bricken.

 

[W!ldGunM@n]

1. Baue ich keinen eigenen Kernel, ich verwende den Kiwi-Kernel.
2. Ich flashe zu testzwecken mehrmals am Tag... ohne das irgendwas passiert... für mich sieht der Thread hier langsam nach Paranoia aus...

 

[vetzki]

Ich glaub eigentlich auch nicht das das recovery den Bug auslösen kann (soweit ich weiß sind bisher 3 tablets hier im forum gebricked, meins, spocks, "hab den Namen leider vergessen" ). Warum genau weiß keiner (obs überhaupt dieser Brick Bug ist??? ). Wenn das Recovery diesen auch auslösen könnte hätts imo schon mehr getroffen.

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

 

[jpo234]

Euer Wort in Gottes Ohr.

 

[vetzki]

Warum testest es du nicht einfach?

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

 

[u.k-f]

Weil manche Autofahrer beim Schalten vom dritten in den vierten Gang das Kuppeln vergessen und somit ihr Getriebe beschädigt wurde, wird auf Einschlägigen Internet-Foren empfohlen, den Schalthebeln in der Position des ersten Ganges mit ein paar Schweisspunkten zu befestigen.

Grüsse Uwe

 

[vetzki]

lol

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

 

[jpo234]

Warum testest es du nicht einfach?

Einen Kernel backen ist kein Problem. Ein volles Recovery habe ich noch nie gemacht.

 

[u.k-f]

Einen Kernel backen ist kein Problem. Ein volles Recovery habe ich noch nie gemacht.

Man ist nie zu alt, was neues zu lernen. Immer nur das zu machen, was man schon kann, hält einen geistig nicht in Topform, nur das Bestreben, sich neue Fähigkeit anzueignen, erhält den Geist in Topform....

Grüsse Uwe

 

[vetzki]

Einen Kernel backen ist kein Problem. Ein volles Recovery habe ich noch nie gemacht.

Du könntest ja ggf. das vorhandene nehmen und mit dem Kernel neu packen. Sollte ja an sich gehen denke ich.
Vll. is ja manchen so lieber dann kann jeder selbst wählen.
Grüße

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

 

[jpo234]

Nach dem neuerwachten Interesse an CM10.1 habe ich dort auch mal in den Quellen herumgestöbert und bin in der A700-Konfiguration auf folgendes gestossen (device/acer/t30-common/BoardConfigCommon.mk):

# Samsung EMMC brick bug
# Already disabled in kernel, but disable again for safety
BOARD_SUPPRESS_EMMC_WIPE := true

 

[u.k-f]

Dass es Menschen gibt, die glauben, dass das Problem eines Samsungs sich auf einen Acer überträgt, ist hinreichend bekannt.

Es steht Dir ja frei, einen Kernel, oder ein CWM oder was auch immer Du magst mit dem O.A. Setting zu veröffentlichen.

Würde mich freuen, was von Dir zu sehen...

Grüsse Uwe

 

[jpo234]

pawitp hat unter anderem die Cyanogenmod ports für Acer A700, Galaxy Grand Duos, Samsung Galaxy S gemacht. Aussagen von ihm würde ich verdammt ernst nehmen.
Dass das Problem initial auf Samsung-Geräten entdeckt worden ist, heißt nicht, dass es nur auf solche beschränkt ist.