[Diskussion] CyanogenMod 7 für das Milestone (CM7)

[fipsy]

Hi Loader009!

Was deine Aussagen zur Festplatte betrifft, hast du das völlig richtig erklärt.

Was den Flash betrifft, stimmt es aber nicht so ganz. Flash-Speicher muss vor jedem Schreib- oder Lesevorgang adressiert werden und diese Adressierung benötigt erheblich Zeit. Das entspricht etwa der Zeit, die die Festplatte für die Kopfpositionierung benötigt. Wird Flash hingegen sequentiell gelesen oder geschrieben, so wird nur einmal am Anfang adressiert und dann werden nur noch die Datenblöcke (Pages) rüber geschoben. Daher geht sequentielles Lesen und Schreiben auch beim Flash erheblich schneller, als Random-Zugriff. Die von mir gezeigten Daten von CrystalDiskMark für eine SD-Karte sind daher absolut realistisch. Es kann sein, dass bei jedem Cluster neu adressiert werden muss. Da kenne ich mich bei SD nicht so genau aus. Aber auf jeden Fall ist sequentielles Lesen/Schreiben mit deutlich weniger Adressierungsvorgängen verbunden.

Ich glaube, du hast Cluster und Sektoren verwechselt. Ein Sektor hat 512 Bytes. Auf einer Festplatte ebenso wie auf einer SD-Karte. Normalerweise sind mit FAT32 vorpartitionierte SD-Karten mit 64 Sektoren je Cluster partitioniert. D.h. jeder Cluster hat 32 kB und jede Schreib- und Leseoperation muss daher mindestens 32 kB verarbeiten. Hat man viele kleine Dateien, ist diese Clustergröße daher nicht sinnvoll. Ext2-vorformatierte SD-Karten kenne ich nicht, weshalb ich nicht weiß, was dort die Standard-Clustergrößen sind.

Wenn du deine SD-Karte selbst partitionierst, kannst du die Clustergröße aber selbst auswählen. Ich habe z.B. 8 Sektoren je Cluster genommen, das sind 4 kB, was dann auch die kleinste zu verarbeitende Datenmenge ist. Für Ext2 und Linux Swap habe ich die Vorgaben des Partition Wizard stehen lassen, weil ich mich da nicht so gut auskenne. Er hat bei der Ext2-Partition 2 Sektoren je Cluster genommen (1024 Bytes). Für Linux Swap gibt es keine Clusterangaben. Vermutlich wird das Swap-System von Linux intern verwaltet und ist sektorbasiert. Aber das weiß ich nicht so genau. In jedem Falle finden Adressierungsvorgänge statt und somit gilt beim Swap das selbe, wie für alle anderen Partitionen: Je weniger Adressierungen, desto besser/schneller ist der Datentransfer.

Geswapt werden m.W. eigentlich immer ganze Prozesse und nie Teile davon. Das bedeutet auch, dass beim 'swappen' immer relativ große Datenmengen bewegt werden. Nämlich die Größe, die das Programm im Speicher belegt. Also i.d.R. zwischen 4 und 28 MB. Da ist ein sequentieller Zugriff von erheblichem Vorteil.

Eine Bewertung dieser Vorgänge kann man abschließend nur vornehmen, wenn man weiß, wie Linux die Swap-Partition verwaltet. Das weiß ich aber nicht. Auf jeden Fall spielt es eine Rolle, ob beim Swappen kleine Datenschnipsel mit häufigen Adresswechseln gelesen werden, oder große Datenmengen mit wenig Adressierungen. Zu adressmäßigen Defragmentierungen kommt es dabei ganz sicher auch, denn jeder Datenträger muss ja adressiert werden und dies kann leider aus logistischen Gründen nicht immer fortlaufend erfolgen, da Daten unterschiedlicher Größe auch wieder gelöscht werden und die Lücken irgendwie gefüllt werden müssen. Das kann man natürlich so machen, dass möglichst wenig Fragmente auftreten oder man kann zwischendurch defragmentieren. So wird auch Linux das tun. Je mehr adressiert wird, desto langsamer wird auch beim Flash der Zugriff. Wie bei einer defragmentierten Festplatte.

Solche Probleme gibts übrigens sogar beim RAM im Rechner. Auch dort wird hin und wieder vom Betriebssystem eine Reorganisation vorgenommen, damit der Zugriff schneller wird, weil Adressieren eben viel Zeit kostet. Nur merkst du davon nichts . Nennt sich übrigens "Memory Compaction" und auch Linux macht das regelmäßig: Memory compaction [LWN.net]

 

[bingo5]

Geswapt werden m.W. eigentlich immer ganze Prozesse und nie Teile davon. Das bedeutet auch, dass beim 'swappen' immer relativ große Datenmengen bewegt werden. Nämlich die Größe, die das Programm im Speicher belegt. Also i.d.R. zwischen 4 und 28 MB. Da ist ein sequentieller Zugriff von erheblichem Vorteil.

Zu deinem gesamten Beitrag kann ich nicht viel sagen, hört sich gut, logisch und interessant an - allerdings kenne ich mich nicht aus in wie fern Adressierung wirklich ein Performanceeinbruch mit sich bringt, daher kann ich es weder bestätigen noch dementieren

Aber der zitierte Absatz, stellt mir eine Frage auf die mich schon seit Einführung des Swapsupports beim MS beschäftigt...

Ist es wirklich so dass beim Swap sequenziell gelesen wird?
Meiner Meinung nach nicht!

Würde man z.B. eine App auf der SD installieren, dann würde die natürlich bei Zugriff/Öffnen komplett gelesen und in den RAM abgelegt werden.
Nun ist aber die Swap ja der RAM.
Und der RAM ist ja wiederum dazu da um in der jeweiligen App die aufzurufenden Daten schnell bereit zustellen.
Nun ruft eine App aber nicht gleich Tonnen an Information ab, sondern höchstens soviel wie erst einmal in den Cache der CPU passt - dort werden die Informationen verarbeitet und es können wieder neue Informationen abgerufen werden. So entsteht dann eben doch kein sequentielles Lesen.
Des weiteren werden die Daten im RAM ja ständig manipuliert/aktualisiert.

Nehmen wir z.B. ein Spiel, dort gibt es x tausende variable die sich in ständiger Veränderung befinden.. nehmen wir ein ganz einfaches Beispiel.
Wir haben einen Held der auf Level 10 ist, nun sammeln wie XP/Erfahrungspunkte, bei jeden "aufsammeln" solcher Punkte, muss natürlich auch die Variable für die Erfahrungspunkt erhöht werden, das ist jedes mal nur ein kleiner Wert. Haben wir nun genug für Level 11, muss auch die Variable "Level" um 1 erhöht werden.

Ich denke dadurch kommen pro Sekunde eine haufen Operationen zusammen die keinesfalls sequenziell sind.

Aber das ist nur meine Meinung, mehr oder weniger nur auf nachdenken gestützt - ob es sich so wirklich verhält? Aber irgendwo müssen solche Variablen in einer App ja gespeichert werden und deswegen gibt es ja auch so etwas wie ein RAM (der eben extrem hohe Transferraten aufweist)... ich wüsste jetzt nicht wo anderweitig solche Informationen gelagert werden sollten.

edit: Kleine Verbesserung, soviel ich weiß, verlangsamt sich eine SSD (Flash-Speicher basierend), wenn sie voll ist. Ob das nun direkt mit den Zugriffszeiten zusammenhängt oder es der Chip ist, entzieht sich meiner Kenntnis. Ich vermute allerdings, dass es mit der Speicherorganisation der SSD zusammenhängt.

Das liegt, soweit ich weiß, daran dass die Daten bei einer SSD (wie auch bei einer HDD) erst einmal nicht gelöscht werden, sondern nur als gelöscht markiert werden.
Das ist in sofern auch nicht weiter schlimm, neue Daten werden einfach hinten angehängt und wenn die SSD im Leerlauf ist, werden nach und nach die Daten richtig gelöscht (Stichwort Garbage Collectionhttp://de.wikipedia.org/wiki/Garbage_Collection) und können dann wieder beschrieben werden. (Das hat auch den Vorteil das alle Sektoren mehr oder weniger gleichmäßig abgenutzt werden).

Ist nun aber die Platte fast voll, muss während des aktiven Schreibvorganges schon gelöscht werden und das dauert seine Zeit.
Im Gegensatz zu einer HDD die einfach überschrieben werden kann, muss bei einer SSD erst der ganze alte Inhalt gelöscht werden und dann kann der neue eingespielt werden (also doppelte Arbeit).
Die heutigen SSDs sind aber schon wesentlich intelligenter, das Problem mit langsamen SSDs bei voller Platte ist mehr ein Phänomen aus den Anfangstagen von SSDs.
_____________________________________

Doch nochmal bezüglich der Defragmentierung von Flash:
Ganz unabhängig davon ob es Sinn mach der nicht - es verkürzt jedenfalls erheblich die Lebensdauer des Flashspeichers... Denn so eine Speicherzelle hat nur eine begrenzte Lebenszeit in Form von Lese-/Schreibezyklen die sie über sich ergehen lassen kann.
Wenn nun aber durchs Defragmentieren andauernd irgendwelche Daten gelöscht und neu beschrieben werden führt das natürlich so einer extremen Steigung der Zyklen.

Ich möchte zum Sinn/Unsinn von dem Defragmentieren einfach mal Wikipedia zitieren:

Eine Defragmentierung ist aufgrund der geringen Lesezugriffszeiten nicht nötig. In Bezug auf die Schreibleistung differieren die Herstellerangaben jedoch. So warnt OCZ die Nutzer seiner MLC-basierten Core-Serie vor dem Defragmentieren,[51] während MTron für seine SLC-basierten Produkte ein Defragmentieren sogar empfiehlt.[52] Kingston hingegen rät stets vom Defragmentieren ab – ganz gleich, ob für das SLC- oder MLC-Format.[53] Intel rät generell nicht zum Defragmentieren ihrer SSDs.

Fakt ist: vielleicht bringt es war an Performance... aber es bringt auf jeden Fall eine Reduzierung der Lebensdauer

 

[Loader009]

Mein Wissen über Cluster und Sektoren:
Sektoren sind die physikalischen Gruppierungen von Speicher (512 Byte typischerweise?).
Cluster sind Gruppierungen in dem Datensystem, vollkommen unabhängig von den Sektoren.

Ich werde mir die Wiki-Artikel nochmals durchlesen, vielleicht hatte ich was falsch verstanden.

Außerdem, fiel mir eben beim durchlesen ein.
Soviel ich weiß, braucht man ext2/3/4 nicht zu defragmentieren, da das Dateisystem so aufgebaut ist, dass Fragmentierungen von vornherein verhindert werden. Ich gehe stark davon aus, dass eine Swap-Partition sehr ähnlich agiert, aber so genau weiß ich das natürlich auch nicht.
Falls meine Annahme richtig wäre, würde eine größere Swap-Partition nach deiner Definition sogar mehr bringen, denn Fragmentierungen wären seltener als bei einer kleineren Swap-Partition.

Sollte allerdings bingo5 recht behalten und der Swap wird pro Programm nur teilweise genutzt und niemals für ein komplettes Programm, so sind beide Arten gleich gut.


Das war jetzt einfach mal eine Interpretation von dem, was ich hier zusätzlich gelesen habe.
Wie dem auch sei, über den swap lässt sich wirklich lange streiten. Ich probier wahrscheinlich mit der neuen CM7 Version auch mal ne kleinere Einstellung. Allerdings nutze ich Multitasking seit Swap mehr denn je, also gehe ich davon aus, dass ich wenigstens 120MB brauchen werden.


Zu SSD, vermutlich hast du recht bingo5, ich hatte nur im Kopf, dass ich diese Nachteile in kürzlichen Tests gelesen hatte, habe selbst eine Samsung 830, versuche mich daher immer einwenig auf dem laufenden zu halten.

 

[fipsy]

Danke für den Beitrag, bingo5!

Zu deinem gesamten Beitrag kann ich nicht viel sagen, hört sich gut, logisch und interessant an - allerdings kenne ich mich nicht aus in wie fern Adressierung wirklich ein Performanceeinbruch mit sich bringt, daher kann ich es weder bestätigen noch dementieren

Nun, SD-Karten habe ich bisher auch nicht auf der Hardwareebene bearbeitet, wohl aber "normalen" Flash-Speicher, wie z.B. 24C64 zur Genüge. Und da ist dies ein signifikanter Unterschied. Bei SD wird es nicht wesentlich anders sein, was ja auch die Tests mit CrystalDiskMark belegen.

Ist es wirklich so dass beim Swap sequenziell gelesen wird? Meiner Meinung nach nicht!

Es wäre super, wenn sich dazu ein Linux-Spezi mal äußern könnte! Ich weiß nur, wie es bei Windows ist. Dort werden nur ganze Prozesse sequentiell ausgelagert und bei Bedarf wieder zurückgeswappt.

Sobald der Prozess im Swap ist, läuft er nicht mehr! Er wird dann quasi in einen Suspend (Wartezustand) versetzt. D.h. es wird der gesamte Prozess (Programmcode mit Heap und all seinen Daten) ausgelagert. Wenn der Code / das Programm wieder benötigt wird, muss es zuerst wieder vom Swap (also i.d.R. der Festplatte) zurück in den Arbeitsspeicher geladen werden. Denn der Prozessor holt sich von dort ja seine Instruktionen ab. Von einer Festplatte kann sich der Prozessor die Instuktionen und Daten nicht direkt holen (logischerweise). Denn sonst bräuchte man ja gar keinen Arbeitsspeicher mehr. Ich bin ziemlich stark davon überzeugt, dass es Linux nicht viel anders machen wird ;-).

Würde man z.B. eine App auf der SD installieren, dann würde die natürlich bei Zugriff/Öffnen komplett gelesen und in den RAM abgelegt werden.

Genau so ist das

Nun ist aber die Swap ja der RAM.

Äh, nee! Der SWAP ist ein Festplattenbereich, der zur Aufnahme von Code und Daten dient, die momentan nicht benötigt werden und daher unnötig RAM belegen. Die werden dort hingeschoben und quasi "zwischengeparkt". Programme, die da liegen, laufen nicht mehr. Sie sind aber bei Bedarf jederzeit wieder in ihren vorherigen Zustand zurückzuversetzen, indem man sie ins RAM zurück lädt.

Man korrigiere mich, wenn ich mich da irre, aber Swap ist auch unter Linux sicher keine RAM-Erweiterung.

Aber das ist nur meine Meinung, mehr oder weniger nur auf nachdenken gestützt - ob es sich so wirklich verhält?

Du hast so weit richtig gedacht, nur mit dem Ausgangsfehler, dass Swap eben kein RAM ist.

Das liegt, soweit ich weiß, daran dass die Daten bei einer SSD (wie auch bei einer HDD) erst einmal nicht gelöscht werden, sondern nur als gelöscht markiert werden.

Genau. Da liegt der Knackpunkt. Flash ist nicht beliebig oft beschreibbar. Der von mir oben zitierte Baustein ca. 1 Million mal. Das variiert von 100.000 Mal bis zu 10 Millionen mal. Daher finde ich es auch immer sehr gewagt, eine "Lifetime Warranty" auf SD-Karten zu geben, wie Kingston es z.B. tut. Das impliziert, dass diese Karten im Grunde beliebig oft beschrieben werden können, ohne Defekte aufzuweisen. Das ist aber definitiv nicht so. Außerdem ist die Daten-Lagerzeit auch nicht beliebig groß. Die Daten werden nach etwa 40 Jahren unbrauchbar. Das ist bei Foto-Archiven zu beachten!

Wie die Karten intern letztlich organisiert sind, weiß nur der Hersteller. Nach außen hin haben sie jedoch Sektoren zu 512 Bytes, die adressiert werden können. Ob die SD nun intern erstmal alles voll müllt, um dann irgendwann Daten zu löschen, um so eine gleichmäßige Ausnutzung zu gewählrleisten, bleibt das Geheimnis des Herstellers.

Der große Unterschied zwischen Flash und Festplatte ist hier wohl, dass bei der Festplatte ein Sektor immer die selbe physikalische Position auf der Platte hat. Ich könnte also einen bestimmten Sektor mit einer Stricknadel zerstören, wenn ich wüsste, wo er genau liegt. Bei der SD-Karte gibt es einen solchen, physikalischen Zusammenhang nicht. Der selbe Sektor kann mal hier und mal dort im Flash-Speicher liegen. Das bleibt der SD-Karte überlassen. Wobei man ehrlicherweise sagen muss, dass auch bei Festplatten dieser Zusammenhang nicht immer gegeben ist. Moderne Platten (ab IDE) haben auch interne Managementsysteme, die defekte Sektoren erkennen und sie bei Bedarf in reservierte Bereiche verschieben. Davon kriegt der Nutzer gar nichts mit. So kann dann auch bei einer Festplatte ein Sektor "wandern". Aber eben nur, wenn er defekt ist und durch das Verschieben automatisch "repariert" wird. Der Vorteil ist, dass auch eine leicht defekte Festplatte noch lange überleben kann und man von dem Defekt gar nichts merkt. Früher musste man sie sofort wegschmeißen (alte ISA-Platten, die noch Low-Level formatiert werden konnten, siehe hier). SD-Karten machen das übrigens auch so.

Der ursprüngliche Beitrag von 18:06 Uhr wurde um 18:38 Uhr ergänzt:

Cluster sind Gruppierungen in dem Datensystem, vollkommen unabhängig von den Sektoren.

Ähm, eigentlich nicht . Jeder Cluster enthält n logisch zusammenhängende Sektoren. n kann dabei bei der Partitionierung frei gewählt werden (zumindest bei FAT32- und Ext-Partitionen).

Außerdem, fiel mir eben beim durchlesen ein.
Soviel ich weiß, braucht man ext2/3/4 nicht zu defragmentieren, da das Dateisystem so aufgebaut ist, dass Fragmentierungen von vornherein verhindert werden.

Grins. Sagen wir mal so: Das Ext-Dateisystem wird so verwaltet, dass Fragmentierungen so weit wie möglich vermieden werden. Ausgeschlossen sind sie trotzdem nicht. Dort findet quasi eine laufende Defragmentierung statt, von der der Benutzer nichts merkt. So ähnlich wie mit "Puran Defrag" unter Windows, was ich übrigens wärmstens empfehlen kann!

Falls meine Annahme richtig wäre, würde eine größere Swap-Partition nach deiner Definition sogar mehr bringen, denn Fragmentierungen wären seltener als bei einer kleineren Swap-Partition.

In dieser Argumentation hast du damit Recht. Aber eine größere Partition heißt auch, dass CM7 viel mehr Daten auf die Partition auslagert, statt sie durch Beenden des Tasks einfach aus dem RAM zu entfernen. Das bedeutet letzlich eine deutliche Verlangsamung des Systems, weil du eine Menge Apps im Swap mit dir rumschleppst, die eigentlich schon längst hätten aus dem Speicher entfernt werden können.

 

[TeCci]

Ich stoere ja nur ungern bei euerm doch sehr interessantem Gespraech, aber ich wollte nur mal bekunden, dass ich dasselbe Problem wie fipsy habe bzw. hatte mit dem einstellen des Swaps.

Swap Partition = 48MB

Mit dem Wert 49152 via Terminal Emulator bei laufendem CM7 und nem reboot kam bei der Abfrage "free" 0 - 0 - 0 raus.
Mit 32576 danach dann die Zahlen, die bestaetigen, dass Swap aktiv ist.

Habs dann gestern Abend so gelassen weils erstmal wieder lief und ich keine Lust mehr hatte .

Ergo: die Swap zu aktivieren geht. Auf die Maximalgroesse einzustellen geht nicht. Mit einem Utopischen Wert ( z.b. 9999999 ) hab ich es nicht ausprobiert, um zu testen, ob das Build einen zu grossen Wert automatisch aufs Maximum setzt, denn ich hatte ja keinen zu grossen sondern den maximalen probiert .

 

[android.outliner]

Leider behebt 7.2.4c die Lags nicht. Tauchen noch immer verläßlich nach 2 Tagen Betrieb auf und sind nach dem Reboot verschwunden.

 

[fipsy]

Swap Partition = 48MB

Das Problem ist, dass meist nur gerundete Werte als Größe angezeigt werden. So war meine Swap auch 48 MB groß laut einiger Anzeigen. Aber die wahre Größe war (laut Partition Wizard) 47,07 MB. Nachdem ich dann 47*1024 = 48128 als Größenangabe gesetzt hatte, trat das Problem nicht mehr auf. Das ist auch der Grund, warum nadlabak die Größe in kB und nicht in MB angeben lässt (jemand fragte weiter oben danach). Sonst könnten "krumme" Partitionsgrößen nicht genutzt werden. Trotzdem ist das Verhalten anders, als nadlabak es weiter oben beschrieben hat. Ich denke, in 12swap ist da noch ein Fehler.

Der ursprüngliche Beitrag von 23:36 Uhr wurde um 23:38 Uhr ergänzt:

Leider behebt 7.2.4c die Lags nicht. Tauchen noch immer verläßlich nach 2 Tagen Betrieb auf und sind nach dem Reboot verschwunden.

Hatte ich auch immer. Welchen Governor benutzt du?

 

[-FuFu-]

ich werd dann jetzt erstmal auf die neue Version updaten ich komm da irgendwie nie zu

 

[FZelle]

Daher finde ich es auch immer sehr gewagt, eine "Lifetime Warranty" auf SD-Karten zu geben, wie Kingston es z.B. tut.

Wear leveling - Wikipedia, the free encyclopedia

Wenn es das nicht gäbe, gäbe es auch keine modernen SSD's.

 

[fipsy]

Wear leveling - Wikipedia, the free encyclopedia

Wenn es das nicht gäbe, gäbe es auch keine modernen SSD's.

Danke für den Hinweis! Das bestätigt ja das, was weiter oben auch schon geschrieben wurde. Dennoch ermöglichen noch so ausgefeilte Mechanismen keine "Lifetime Warranty". Lifetime bezieht sich dabei ja subjektiv auf die vom Kunden vorgesehene Einsatzdauer. Im schlimmsten Falle also so lange, bis der Kunde stirbt. In Deutschland/Europa sind solche Angaben eh unwirksam. Aber in den USA und Kanada z.B. heißt das wirklich lebenslang, soweit ich weiß.

Die SD-Karten haben ohnehin eine deutlich geringere Lebensdauer, als EEPROM-Bausteine, wie der oben von mir zitierte 24C64. Diese haben auch ohne "wear leveling" 1-10 Millionen Schreibzyklen je Speicherzelle. Das liegt aber vermutlich daran, dass die Zellen größer sind als auf einer SD und daher mehr Ladung aufnehmen können.

Trotzdem kann ich mir kaum vorstellen, dass eine SD nur 3000-5000 Schreibzyklen ermöglicht. Wenn man bedenkt, wie oft in der Swap-Partition rumgeschrieben wird, wäre die SD-Karte dann schon nach einigen Monaten hinüber.

Der ursprüngliche Beitrag von 17:16 Uhr wurde um 17:21 Uhr ergänzt:

ich werd dann jetzt erstmal auf die neue Version updaten ich komm da irgendwie nie zu

Also ich habe das Update auf meinem Arbeitsgerät jetzt erstmal verschoben. Ich hatte es auf meinem Testgerät nun schon zweimal, dass die FAT32-Partition der SD-Karte beim Booten nicht korrekt gemounted wurde. Das hatte ich bei der 7.2.4b noch nie! Einmal war die Karte nur read-only gemounted, was dazu führte, dass alle Anwendungen abkackten, die auf die FAT32-Partition zugreifen wollten und gerade vorhin war die FAT32-Partition gar nicht gemounted worden. Nach dem Booten stand in der Statuszeile "Die SD Karte kann jetzt entnommen werden". Irgendwie ist in der 7.2.4c noch der Wurm drin, glaube ich. 12swap funktioniert ja auch nicht so, wie es eigentlich sollte.

 

[-FuFu-]

ich hab jetzt auf beiden Geräte die aktuelle cm7 drauf bisher ohne fehler...
aber ich nutzt die 12swap nicht ^^ ich nutz weiterhin meine 98swapon

das problem mit der sdcard hatte ich nur einmal unter cm9 gehabt, da lag es an fehlern auf der fat partition, was sich durch die windows fehlerprüfung beheben lies

ansonsten laufen beide geräte flüssig

 

[fipsy]

Ich warte mal ab. Ich finde es auch nicht so schön, dass man mit der kamerataste während des bootvorgangs das Display nicht mehr dimmen kann und man minutenlang grell bestrahlt wird. ;-)

Also es gibt mehreres, was nicht so ganz optimal ist.

 

[GARSTIG]

Der Fehler bei der 12swap lag daran, dass in dieser Code verwendet wurde, welchen die Shell in Gingerbread nicht versteht. Nadlabak hat aber schon einen Fix hochgeladen, der wohl in der nächsten Version dabei sein wird.

MfG AddiB

 

[hoagie]

Hallo zusammen,

gerade wollte ich auf die Version 7.2.4c updaten. Aber immer wenn ich in der openrecovery war hat sich das Handy einfach neu gestartet, egal was ich gemacht habe - auch wenn ich es nicht angefasst habe. Ich habe CM 7.2.4b installiert und die MiniMod OR V0.22 benutzt.

Kennt vielleicht jemand das Problem und kann mir helfen?

Gruß
hoagie

 

[fipsy]

gerade wollte ich auf die Version 7.2.4c updaten. Aber immer wenn ich in der openrecovery war hat sich das Handy einfach neu gestartet, egal was ich gemacht habe - auch wenn ich es nicht angefasst habe.

Ja, das hatte ich mit der Open Recovery von nadlabak auch ständig. Nach 30 Sekunden startete das Gerät einfach neu. Es ist laut FuFu ein bekanntes Problem. Keiner weiß wohl zur Zeit, woher das kommt.

Ich habe dann die MiniMod von FuFu genommen und das Problem trat nicht mehr auf. FuFu sagt aber selbst, dass es bei seiner MiniMod auch vorkommt. Ich habe es bei dieser bisher nur einmal gehabt. Mir scheint sie stabiler zu sein. Aber bei dir sieht es wohl anders aus. Vielleicht probierst du mal die Androidiani OR (https://www.android-hilfe.de/forum/...estone.60/androidiani-openrecovery.47776.html) oder die von nadlabak (OpenRecovery_2ndbootOR_v1_1.zip). Androidiani hat allerdings noch keine 2ndboot, wenn ich das richtig sehe?!

Gruß, Volker

 

[hoagie]

Danke!
Mit der Androidiani OR hat es funktioniert, bei der OR von nadlabak war das selbe Problem wie bei der MiniMod OR zuvor.

 

[fipsy]

Danke!
Mit der Androidiani OR hat es funktioniert, bei der OR von nadlabak war das selbe Problem wie bei der MiniMod OR zuvor.

Das deutet für mich stark darauf hin, dass es was mit dem Kernel der 2ndboot zu tun hat! Wäre doch mal ein Hinweis für diejenigen, die den neuen Kernel gebaut bzw. implementiert haben .

 

[Otandis_Isunos]

Hallo zusammen,

gerade wollte ich auf die Version 7.2.4c updaten. Aber immer wenn ich in der openrecovery war hat sich das Handy einfach neu gestartet, egal was ich gemacht habe - auch wenn ich es nicht angefasst habe. Ich habe CM 7.2.4b installiert und die MiniMod OR V0.22 benutzt.

Kennt vielleicht jemand das Problem und kann mir helfen?

Gruß
hoagie

Das Problem hatte ich bei meinem Schwager seinem Milestone auch. Es ging, wo es eingeslidet war und nicht am Kabel hing. Da muss man zwar mit den Seitentasten navigieren, aber anders hab ich nicht flashen können.

 

[-FuFu-]

das Problem tritt sporalisch auf, es kann an einer defekten Datei liegen (download- oder kopierfehler)... nadlabak hatte irgendwann mal erwähnt, das es auch an der Akkuerkennung liegen kann, das er als leer erkannt wird und daher neustartet (ähnliches gibt es ja mit nachgemachten akkus unter cm7/9/10 wenn man die 1% schritte nutzt)...
eine zuverlässige lösung gibt es allerdings nicht, da sich das Problem einfach nicht reproduzieren lässt, ich hatte das ganze auch 1 mal bei mir, ich konnte das Problem bei mir lösen indem ich zuerst per Windows die sdcard auf fehler geprüft hab, dann den OpenRecovery Ordner gelösch und wieder neu drauf kopiert habe...

und ja, es liegt am 2ndboot Kernel, da dieser funktionen bereit stellt, die es in der Original OR nicht gibt (Akku laden z.b.) und da kann es schon möglich sein, das irgendwas eine Kernelpanic auslöst und das Gerät dadurch neustartet...

einzige zuverlässige ist eine OR zu nutzen, die noch kein 2ndboot nutzt, wobei nach Berichten meine v0.21 das problem nicht haben soll, die Version hat noch die erste 2ndboot Version, wer meine MiniMod nutzen will muß auf v0.10 zurück gehen, die ist noch ohne 2ndboot, allerdings fehlen dort auch noch viele funktionen...


aber nun mal back to topic
hab die neue cm7 nun auf beiden geräten drauf, Akkuverbrauch ist okay soweit, 2d 13h 20m und noch 30% übrig, hauptverbraucher ist WLAN mit 57% da es genau so lange an ist
ansonsten läuft es wie gewohnt flüssig und ich hab soweit keine Probleme oder Fehler bis jetzt...
das neue 12swap script nutz ich nicht, war das erste was gelöscht wurde ^^ ich hab mir ja nicht umsonst nen eigenes script geschrieben

da aber google play music nur probleme macht, bin ich auf den player umgestiegen: https://play.google.com/store/apps/details?id=com.jrtstudio.music
da dort auch die titelwahl per Lautstärketasten funktioniert, und für mich hat er alles funktionen die ich brauch (zufallswiedergabe, mehr brauch ich nicht ^^)

 

[fipsy]

Kann ich bestätigen, 7.2.4c ist vom Akkuverbrauch her unauffällig gegenüber den älteren Versionen. Und auch sonst gab es keine unerwarteten Reboots oder andere gravierende Probleme, die mit dem System zusammenhängen.

Das einzig für mich Unschöne ist, dass man beim Bootvorgang mit der Kamerataste das Display nicht dimmen kann und dass 12swap nicht ganz optimal funktioniert. Die Sache mit den falsch gemounteten FAT32-Partitionen beobachte ich weiter. Ich bin mir nicht sicher, ob da ein Zusammenhang zur 7.2.4c besteht. Ein Fehler auf der FAT32-Partition der SD-Karte war es jedenfalls nicht (wie von FuFu als mögliche Ursache vermutet).