[Sammelthread] S3 startet nicht mehr / Sudden Death Problem!

[MMcFly267]

@littleDave

hast du schonmal einen anderen Kernel versucht?

Eventuell kann es auch an einer App liegen, die das System lahm liegt.

Dies hat aber leider/zum Glück (noch) nichts mit dem SD zu tun, da er bei dir ja noch nicht besteht.

 

[littleDave]

Ich habe Samstag Abend noch den aktuellen boeffla-kernel geflashed (2.6-beta1) und hatte Sonntag Abend wieder einen Freeze. Heute hatte ich noch keine Probleme - aber das kann purer Zufall sein. Ich muss mal schauen, wie sich das die Tage noch entwickelt.

An den Apps kann es eigentlich nicht liegen. Die Freezes haben ohne eine Änderung der Apps (auch keine Aktualisierungen) in den Tagen davor angefangen. Auch ohne eine einzige App ist das Telefon schon mehrfach beim Einrichten nach einem Werks-Reset stehen geblieben - mit XELLA ohne Root.

 

[TimeTurn]

für alle die den (ungefixten) Siyah Kernel 1.8.6 nutzen...Die Version 1.8.7 ist rausgekommen und beruht jetzt auf dem Update 7 Quellcode und beinhaltet damit auch den Sudden Death Fix.

Das kann ja jetz echt nich sein - die letzten Tage hab ich dauernd nach ner neuen Version geschaut und nie war eine da, bin nun seit gestern Abend (!) auf Bueffla 2.6 Beta1 und JETZ kommen die um die Ecke *facepalm*...

 

[Husky]

Das kann ja jetz echt nich sein - die letzten Tage hab ich dauernd nach ner neuen Version geschaut und nie war eine da, bin nun seit gestern Abend (!) auf Bueffla 2.6 Beta1 und JETZ kommen die um die Ecke *facepalm*...

Mit freundlichen Grüßen, Husky!



[Kernel: Yank 1.4v/ Testphase]
[ROM: CM 10.1 Nightly]
[CPU: 1,6 GHz/ Lulz Row]

 

[scarface1991]

Hallo,

in einem anderen Forum hab ich folgende Email von Samsung zum Thema Sudden Death gefunden.

irgendwie verwirrt mich das ganze.Ich dachte Samsung arbeitet bereits an einem Fix umd das Problem zu beheben?Hier im Forum hat man auch nicht den Eindruck als wären nur Geräte aus Großbritanien betroffen?Alles sehr merkwürdig.

Mir scheint, dass der Support nicht den blassesten schimmer hat. Das Phänomen ist bisher nur bei eMMC Chips des Typs VTU00M und der Revision 0XF1 aufgetreten, da der Fix beim Quellcode des Update7 darauf hinweißt und tatsächlich gab es bisher noch keinen stichhaltigen beweis, dass es bei anderen eMMC Chips aufgetreten ist, oder dass es aufgetreten ist, obwohl man einen Kernel benutzt, der einen Fix enthält. Es gibt ein paar Berichte, wo einige Geräte auf einmal tot waren, obwohl sie einen Kernel installiert hatten mit Fix, aber wenn man genauer nachfragt, dann sieht man dass diese Leute schon SD Symptome hatten (Ruckeln und reboots) und sich dann eine Firmware geflasht haben, die einen gefixten Kernel enthält, nur ist es dann natürlich schon zuspät.

Ist jemandem ein Fall bekannt, wo das Handy auf einmal tot war, obwohl ein gefixter Kernel installiert war? Mir jedenfalls nicht.

Das Problem ist aber ganz sicher nicht auf Großbritannien fixiert, sondern ein weltweites Phänomen (siehe XDA SD Thread). Da hat der Samsung Support in dem Fall einfach keine Ahnung.

 

[Atlantis66]

Mir scheint, dass der Support nicht den blassesten schimmer hat. Das Phänomen ist bisher nur bei eMMC Chips des Typs VTU00M und der Revision 0XF1 aufgetreten, da der Fix beim Quellcode des Update7 darauf hinweißt und tatsächlich gab es bisher noch keinen stichhaltigen beweis, dass es bei anderen eMMC Chips aufgetreten ist, oder dass es aufgetreten ist, obwohl man einen Kernel benutzt, der einen Fix enthält. Es gibt ein paar Berichte, wo einige Geräte auf einmal tot waren, obwohl sie einen Kernel installiert hatten mit Fix, aber wenn man genauer nachfragt, dann sieht man dass diese Leute schon SD Symptome hatten (Ruckeln und reboots) und sich dann eine Firmware geflasht haben, die einen gefixten Kernel enthält, nur ist es dann natürlich schon zuspät.

Ist jemandem ein Fall bekannt, wo das Handy auf einmal tot war, obwohl ein gefixter Kernel installiert war? Mir jedenfalls nicht.

Das Problem ist aber ganz sicher nicht auf Großbritannien fixiert, sondern ein weltweites Phänomen (siehe XDA SD Thread). Da hat der Samsung Support in dem Fall einfach keine Ahnung.

Samsung hat vermutlich Nur eine wage Vermutung über die Fehlerquelle und weiteres weiß man eben nicht.

Man schreibt zwar hier, dass nur ein kleiner Anteil der 30 Millionen mal verkauften Geräte betroffen sei aber, wie hoch ist die wirkliche Anzahl Weltweit?

Wer kennt von denen Android-Hilfe oder XDA oder sonstige Foren, um den tot seines Gerätes feststellen zu lassen oder gar dies zu melden..

 

[TimeTurn]

Ich hab vorsorglich ein altes Ladegerät fürs S1 genommen und in Stweaks (Siyah kernel Tweaks) den Ladestrom auf 800mA begrenzt - reicht mir völlig da das eh immer über Nacht läd (jemand hatte hier ja geschrieben das die Überstromsicherung seines Labornetzteils angeschlagen hatte, das S1-Netzteil liefert max. 700mA)

 

[Atlantis66]

Ehrlich gesagt, ich habe noch nie mit dem mitgeliefertem Netzteil aufgeladen, da ich noch einen vom Ace hatte und der Neue ist noch unbenuzt und liegt noch in der Original Schachtel.

Gesendet von meinem GT-I9300 mit Tapatalk 2

 

[Rob2222]

Huhu,

so, noch ein paar Infos für die technisch versierten/interessierten User hier...

Oranav bei den XDA-Devs hat sich hingesetzt und den "Fix" disassembliert und analysiert. Er hat damit bestätigt, was wir bis jetzt angenommen haben.

Siehe sein Thread dazu:
eMMC sudden death research - xda-developers

Die normale Situation ist, daß der eMMC-Chip beim Aktivieren die eMMC-Firmware in den eMMC-RAM lädt. Das passiert alles auf dem eMMC-Chip. Jetzt kommt der Fix aus dem Kernel dazu und patcht (verändert) das eMMC-Hauptprogramm im eMMC-RAM.



Theoretisch könnte man wohl auch die eMMC-Firmware selber updaten, aber Entropy meinte, daß er davon ausgeht, daß ein festes/bleibendes Update der internen eMMC-Firmware mit einem kompletten Format des eMMC-Chips verbunden ist. Das heißt wenn man den Chip updaten würde, würde zu einem gewissen Zeitpunkt des Updates komplett leer sein. Kein Bootloader, kein Kernel, keine PIT, kein EFS, kein Garnnichts. Man müßte sich drauf verlassen, daß die wichtigsten Dinge (Bootloader) nach so einem eMMC-Firmwareupdate wieder aus dem S3-RAM korrekt wiederhergestellt werden können. Die Aktion ist einfach zu risikobehaftet, sodaß ein permanentes eMMC-Firmwareupdate von Samsung im Feld auch bei den früheren eMMC-Problemen nicht durchgeführt wurde. Das also als Grund, wieso die eMMC-Firmware "nur" im eMMC-RAM gepatcht wird und das deswegen bei jedem eMMC-Start gemacht werden muss.



Der Fix selbst ist sehr sehr klein, deswegen kann man nur mit dem Disassembling nur bedingt Informationen zur Funktion kriegen. Um die Funktionalität des Fix komplett zu verstehen, müßte man ein Blick auf das Programm im eMMC-RAM werfen können, wo der Fix eingesetzt wird.
Oranav hat einen Weg gefunden, wie man da rankommen kann, wollte es aber nicht versuchen, da er kein Ersatzgerät hat und damit potentiell sein eigenes S3 riskieren würde.
Im Endeffekt konnte er aber scheinbar doch nicht widerstehen :
eMMC sudden death research - xda-developers



Desweiteren hat er einen Siyah 1.8.7 Kernel, der den Fix bereits enthält gepatcht, damit wir prüfen können, ob der Fix auf dem eigenen Gerät aktiv ist. Das heißt mit der Installation des Kernels und dem Ausführen des von ihm geposteten Befehls, kann man feststellen, ob der eigene eMMC-Chip betroffen ist oder nicht. Also man kann feststellen, ob der Fix "aktiv" ist. Damit der Fix aktiv ist braucht es drei Bedingungen. Einmal den Chip VTU00M, dazu die eMMC-Firmwareversion 0xf1 und dazu noch das eMMC-Firmwaredatum der 13.04.2012 sein. (Das ist übrigens ein Freitag, der 13. ) Das Firmwaredatum des eMMC-Chips können wir nicht prüfen, deswegen ist diese Methode mit dem Kernel die erste zuverlässige Methode zu erkennen, ob man selbst betroffen ist.
[Important] Sudden Death Fix - Are you covered? - Page 54 - xda-developers

Aufgrund dessen, daß man dafür diesen gepatchten Kernel flashen muß und im Terminal ein Kommando ausführen muß, ist dieser Test aber vorerst nur für versierte User zu empfehlen. Wer weiß, was er machen muß, kann es prüfen. Wer es Aufgrund dieser Infos hier noch nicht verstanden hat, sollte es erstmal lassen.

Wer es testet, kann hier im Post gerne das Ergebnis posten.

Ich finde das Engagement von Oranav gut. Wer bei den XDA-Devs registriert ist, kann ja mal auf die drei Links hier klicken und ein "Thanks" für sein Engagement dalassen.

Gruß
Rob

PS: Bei neuen Infos hierzu, werde ich DIESEN Post hier erweitern.

 

[Greco.]

Hallo!
Ich wollte fragen, ob der Fix bei der XXELL4 enthalten ist, oder muessen wir auf die XXELLA warten? :/

Vielen Dank im Voraus!

 

[Rob2222]

Steht im ersten Post.

 

[Greco.]

Steht im ersten Post.

Vielen Dank fuer Deine Antwort
Ich wollte nur nochmal fragen, weil ich habe auf mein S3 die XXELL4, und letzte Woche hat sich das Handy von selbst neu gestartet. Ist das nicht ein SDS Symptom?

 

[Rob2222]

@Greco:
Ein Neustart von selbst kann auch viele andere Ursachen haben. IT-Systeme sind nie perfekt.
Solange Dein Handy das nicht regelmäßig macht, brauchst Du Dir da keine Sorgen machen.

Gruß
Rob

 

[Greco.]

@Greco:
Ein Neustart von selbst kann auch viele andere Ursachen haben. IT-Systeme sind nie perfekt.
Solange Dein Handy das nicht regelmäßig macht, brauchst Du Dir da keine Sorgen machen.

Gruß
Rob

Ok, vielen Dank fuer Deine Antwort!

 

[Toxic4u]

Huhu,

so, noch ein paar Infos für die technisch versierten/interessierten User hier...



Desweiteren hat er einen Siyah 1.8.7 Kernel, der den Fix bereits enthält gepatcht, damit wir prüfen können, ob der Fix auf dem eigenen Gerät aktiv ist. Das heißt mit der Installation des Kernels und dem Ausführen des von ihm geposteten Befehls, kann man feststellen, ob der eigene eMMC-Chip betroffen ist oder nicht. Also man kann feststellen, ob der Fix "aktiv" ist. Damit der Fix aktiv ist braucht es drei Bedingungen. Einmal den Chip VTU00M, dazu die eMMC-Firmwareversion 0xf1 und dazu noch das eMMC-Firmwaredatum der 13.04.2012 sein. (Das ist übrigens ein Freitag, der 13. ) Das Firmwaredatum des eMMC-Chips können wir nicht prüfen, deswegen ist diese Methode mit dem Kernel die erste zuverlässige Methode zu erkennen, ob man selbst betroffen ist.
[Important] Sudden Death Fix - Are you covered? - Page 54 - xda-developers


Wer es testet, kann hier im Post gerne das Ergebnis posten.

Also, habe es soeben selber getestet und es ist wirklich einfach, auch für nicht versierte User. Hier Step by Step, wie ihr vorgehen müsst.

1) Phone muß Root haben
2) den gepachten Siyah-Kernel per recovery flashen
3) Android-Terminal-Emulator aus dem Playstore Installieren
4) Terminal-Emulator starten
5) su eintippen und Enter drücken
6) SuperSu fragt nach Admin-Rechten -> erlauben
7) cat /sys/class/block/mmcblk0/device/movi_ops eintippen
8) Enter drücken
9) in der nächste Zeile steht 0 oder 2
10) 0 = Nicht betroffen
11) 2 = betroffen

Das bin leider ich:

Ich habe als Ergebnis eine 2, habe also den Chip mit dem entsprechendem Firmware-Datum.

Kleiner Tip: Den Befehl cat /........... kann man auch per copy&Paste einfügen.

MFG Tox

Taper di Tap with my S3 @183 days

 

[Trabireiter]

ebenfalls betroffen!

Gekauft im Dezember bei MM. Chipdatum (App) ist 7/12.

 

[Toxic4u]

Mein Chip-Datum ist 05/12
Vielleicht machen ja noch mehr den Test und wir können herausfinden, ob ab/bis einem bestimmten Datum die Firmware anders war / geändert wurde.

Bis jetzt also:
Chip-Date 05/12 = Firmware 13.04.2012
Chip-Date 07/12 = Firmware 13.04.2012

Taper di Tap with my S3 @183 days

 

[sonic22]

habe zwar nicht das oben gemacht aber mein chip datum ist 09/12
und
RF 16.10.2012
HW 1.100

 

[Trabireiter]

dann sollten wir evtl die HW-Rev mit aufnehmen

mit *#12580*369#

ich hab die
RF 2012.9.10
HW 1.100

 

[Rob2222]

Bis jetzt also:
Chip-Date 05/12 = Firmware 13.04.2012
Chip-Date 07/12 = Firmware 13.04.2012

Wie schon geschrieben, ich gehe eigentlich davon aus, daß alle 0x1f Firmwares genau dieses Firmwaredatum haben und der Programmierer von dem Fix das Datum nur als zusätzlichen (aber eigentlich unnötigen) Check eingebaut hat. Nach dem Motto, besser Vorsicht als Nachsicht.

Denn, wenn man eine Firmware neu kompiliert, sodaß es zu einem neuen Firmwaredatum kommt, dann kompiliert man diese für gewöhnlich wegen einer Änderung. Und wenn man eine Änderung einarbeitet, daß hebt man eben für gewöhnlich auch die Versionsnummer an.

Gruß
Rob