Die XXMF1 (4.1.2) vom 03. Juni 2013 fürs I8160

[JDfense]

Danke für das Material an alle. Ich schaue es mir nach dem Essen an.

@ Joker
Ich kenne dalvik cache nur als extra Löschpunkt in der cwm und data/factory reset löscht das sonst nicht mit. Das ist also bei Samsung anders.

JDfense

 

[cO5Mo]

C05Mo aber warum bekomme ich bei der BTU dann 550MB ram und nicht 482MB Ram das ganze ist irgendeie total unlogisch ist ja auch ein JB.

Das kann ich Dir auch nicht wirklich sagen. Ich vermute mal, dass die bei Samsung auch erstmal experimentieren mussten, um auf einen stabilen Wert zu kommen. Wir mutmaßen hier ja alle nur mit den zur Verfügung stehenden Daten.
Das ist hier wie dunkle Materie für die Astrophysiker

 

[Wiesel78]

Bitte starte mal Dein Gerät neu und mache es nochmal. Danke

Erledigt
Hab die file aus meinem ersten post gefixt.

 

[payer]

Ich fürchte, dass die RAM-Vergleicherei uns irgenwann in den Wahnsinn treibt.
Hier die dmesg-File-Vergleiche von JDfense, Wiesel78 und mir:

Bei JDfense (482MB)
<6>[ 0.000000] Memory: 96MB 128MB 43MB 239MB = 506MB total
<5>[ 0.000000] Memory: 491056k/982112k available, 54176k reserved, 0K highmem

Bei payer (624MB)
<6>[ 0.000000] Memory: 96MB 128MB 43MB 382MB = 649MB total
<5>[ 0.000000] Memory: 636332k/636332k available, 28244k reserved, 146432K highmem

Bei Wiesel78 (550MB)
<6>[ 0.000000] Memory: 96MB 96MB 382MB = 574MB total
<5>[ 0.000000] Memory: 560172k/560172k available, 27604k reserved, 211968K highmem

Bei Wiesel78 fehlt die 43MB-Partition völlig und er hat nochmal die Hälfte mehr highmem als ich. Interessant, aber es scheint nirgendwo hin zu führen...

Wir könnten jetzt auch noch mit dem Terminal-Emulator die meminfo auswerten und vergleichen:
su
cat /prog/meminfo

Leider zeigt meminfo nur die Verwendung des "verfügbaren" RAMs an und nicht, was für welche Teile des Systems (Baseband, cache usw.) reserviert wurden.

 

[JDfense]

Es ändert sich nicht. Die Dmesg-Ergebnisse für 550 und 624 sind ähnlich unauffällig.
Jetzt heißt es herumfragen, wer weiß, ob unten stehende Zeilen auf einen Fehler in der 482 hinweisen.

<2>[    0.000000] NR_BANKS too low, ignoring high memory
<2>[    0.000000] NR_BANKS too low, ignoring high memory
#
<6>[    0.000000] Memory: 96MB 128MB 43MB 239MB = 506MB total
<5>[    0.000000] Memory: [B][COLOR=Red]491056k/982112k[/COLOR][/B] available, 54176k reserved,[COLOR=Red] [B]0K highmem[/B][/COLOR]

JDfense

 

[terminator64]

So, nach diversen Flash-Aktionen der letzten Monate (von GB 2.3.6 zu JB MB2, dann MB4, dann wieder Downgrade auf GB 2.3.6 und wieder MC8), mit dem Resultat verschiedenster RAM-Angaben (642, 550, 482) habe ich jetzt nochmal ein Downgrade auf GB 2.3.6 gemacht und die XXMF1 geflasht. Jetzt hab ich wieder 482 MB und das Phone läuft sehr flüssig ohne Hänger oder Aussetzer.
Und jetzt ist mir völlig Wurscht wieviel RAM optimal oder normal sind: das Scheissding läuft jetzt wie es soll und wird nie mehr geflasht

 

[a170]

das Scheissding läuft jetzt wie es soll und wird nie mehr geflasht

Sicher????????.

 

[cO5Mo]

Jetzt hab ich wieder 482 MB und das Phone läuft sehr flüssig ohne Hänger oder Aussetzer.
Und jetzt ist mir völlig Wurscht wieviel RAM optimal oder normal sind: das Scheissding läuft jetzt wie es soll und wird nie mehr geflasht

Dem kann ich voll und ganz zustimmen Habe genau die gleichen Erfahrungen gemacht und komme so zum gleichen Schluss wie du.

 

[B3CK3RS]

Ich bin von der BTU (550 MB) direkt auf die XXMF1 mit nun 482 MB und bin auch wirklich zufrieden bisher.

Auch wenn das sicher nicht zwingend ein Indikator sein mag, meine ganz persönlichen Beobachtungen:

Ich höre gern im Hintergrund Musik (div. Player) und spiele währenddessen unterschiedliche Games.
Mit der TMN (624 MB): Viele Ruckler usw.
BTU (550 MB): Nur noch gelegentlich, sodass ich mit dieser Firmware hätte gut leben können.
Die XXMF1 (482 MB): Bisher wirklich einwandfrei. Weshalb ich den Eindruck habe, dass hier die Speicherverwaltung usw. am besten funktioniert.

Ich weiß, dass das so einfach nicht bewiesen ist, die wenigen Tage vllt. ungenügend sind für Vergleiche und habe auch keine Erfahrung mit bspw. der XXMF1 mit 624 MB, aber ICH bin wohl mit der DBT nun gelandet was Jelly Bean angeht

 

[JDfense]

So jetzt habe ich auch endlich mal 624MB mit der MF1.

Der Weg scheint mir klar und ist letztlich auch vielfach genannt, aber ich bin aber noch am warum. In kürze mehr.

JDfense

 

[uxx]

Du wirst aber nicht glücklich auf die Dauer mit den 624 MB. Das Teil rennt und rennt und dann auf einmal kommen diese Blockierungen.
Habe heute bei XDA gelesen, bei der türkischen Variante würde man von GB > JB 624 MB (ohne MB4) erhalten. Verstehe das alles nicht mehr, wozu diese unterschiedlichen Ramversionen bei der 4.1.2 gut sein sollen.

 

[JDfense]

Das Teil rennt nicht wirklich spürbar schneller, aber bisher gut ohne Hänger.
Wie provoziere ich denn die Hänger?

Ja richtig, es geht über MB4 auch rückwärts von der MF1 aus direkt ohne extra pit file. Und dann wieder MF1 flashen, aber die MB4 schön durchbooten und full wipe bei der MB4 machen.

Ich komme in der MB4 nicht weiter. Fast alles .bin files, also compiled und damit Einbahnstraße.Kann man wohl höchstens noch mit einem Hex-Editor reinschauen, aber wird kaum was zu finden sein.
@ Email-Filtering: Würde ja gerne mal in die mem_init reinschauen, ist aber auch eine .bin. Vielleicht steht da drin wie das RAM angesprochen werden soll.

Das pit file ist im ROM enthalten, weshalb es extra auch nicht geflashed werden muss, würde ich annehmen. Jedenfalls liest es odin aus der .tar. Das pit file ist die Grundlage für die partinierung im nand, mehr sehe ich da nicht.Hat folglich mit dem RAM nichts zu tun.
Die zwei enthaltenen imgs sind ext4 partitionen, enthalten aber sicher auch nicht den RAM Zugriff. Bleiben noch ums.rfs und param.lfs, die einen Blick Wert sein könnten - Morgen.

Sollten 624MB keine Stabilitätsprobleme haben, finde ich die Puzzle-ROM-Nummer von Samsung echt schwach. Viele unfertige Versionen ein und derselben Firmware machen noch keinen guten Support, oder? Die ROM Struktur scheint ja verammelt wie Fort-Knox.

Okay soweit mein erster Blick in die firmware.

JDfense
PS.:
Mein 624MB ace 2 liegt bei mir bei 5600 antutus, nicht aufregend für einen duo core, mein tegra 2 oldie hannspad liegt schon bei 6000 antutus ohne Übertaktung, wobei wir das alles nur relativ sehen sollten mit antutu. Wie es sich anfühlt ist entscheidend und da bin ich bis jetzt mit meinem 624erAce2 zufrieden.

 

[Kenchi]

Nabend,

ich habe auch gestern, entgegen meiner Überzeugung in einigen Posts vorher, nochmal auf GB (rus) -> GB (deu) -> MB4 -> MF1 geflasht und erhalte ebenfalls die 624MB.
Gemacht habe ich das, weil ich durch vorheriges flashen GB -> MF1 immer nur recht wenig RAM frei hatte und mit einbildetet, dass das das Smartphone ausbremst. Ob es wirklich so war, weiß ich nicht.
Jedenfalls habe ich mit meiner jetzigen Variante immer wieder Denkpausen, die auch mal bis zu 5 Sekunden dauern können. Sowas war bei GB nicht der Fall und ich finde das schade, dass es so ist. Es kann doch nicht so schwer sein, dass ganze ordentlich aufzusetzen...

Wie wir alle, bin ich total verunsichert, wie es jetzt richtig ist und richtig geht. Wie viele andere benutze ich auch Whatsapp. Mir ist aufgefallen, dass der Ton, welcher kommt wenn eine Nachricht verschickt wurde, mal lauter und mal leiser ist. Das ist äußerst merkwürdig und mit Sicherheit nicht im Sinne des Erfinders. Ob das wohl mit dem rumgeflashe zusammenhängen kann?!

Gibt es nicht jemanden, der richtig in der Materie drin ist und mal ein Machtwort sprechen kann, wie es richtig gemacht wird?

Achja, neu geflasht habe ich auch nur, weil ich auf xda las, dass man vor dem flashen einer JB-Version MB4 flashen solle. Dies bezieht sich aber wohl noch auf eine frühere Version (z.B. die TMN).
Naja, vielleicht flashe ich nochmal neu GB und dann wieder direkt auf JB. Das scheint ja allem Anschein nach, besser zu laufen

 

[JDfense]

Guten Abend Kenchi,

ich denke alle Wege führen über MB4 oder wahrscheinlich geht auch MB2, wenn du 624 MB RAM möchtest. Bei mir läuft das bisher, nur ein paar Stunden stabil, genauso wie mit dem 482er, vielleicht sogar ein Tick knackiger.
Ein Machtwort für den richtigen Weg kann ich nicht aussprechen, aber auf XDA scheint die MB4 auch der Schlüssel zu sein.
Vielleicht will Email-Filtering ja den finalen Weg markieren.

Die Audio-Schwankungen in der Lautstärke haben bestimmt nichts mit dem ROM zu tun. Da bist Du eher auf die Knöpfe gekommen. Smartphone+enge Hosentasche=Bedienungsfehler

Ich hoffe die Denkpausen erreichen mich nicht, aber ich habe auch nicht viele zusätzliche Apps drauf. Hauptfunktion ist das Telefon und die Textnachrichten über verschiedene Wege. Für Spielereien nehme ich ein Tablet.

JDfense

 

[fnast]

Moin,

ist nur ein kleiner Denkansatz, mit Androids Partitionierung bin ich nicht so vertraut (Linux schon), aber könnte es sein, dass mit der PIT von MB4 der SWAP-Speicher vergrößert wurde und dir dadurch fast 1GB RAM angezeigt wird? Wäre für mich die einzig sinnvolle Erklärung. Daraufhin reserviert sich Jelly Bean seinen Speicher, einen Teil vielleicht im SWAP, einen anderen im richtigen RAM, was dazu führt, dass von den 768MB "original RAM" noch 624 MB übrig bleiben, weil JB den SWAP-Speicher füllt?

Würde auch folgender Rechnung entsprechen:

786MB (Gesamtspeicher) - 482MB (freier Speicher) = 304MB (von Jelly Bean reserviert, wenn keine Leaks geflasht wurden)
624MB (Leak-Freier-RAM) + 304MB (Jelly Bean RAM) = 928MB (entspricht ca. der RAM-Größe, die JDefense insgesamt angezeigt wird)

Nur so eine Idee

 

[er1973]

@dhvenus habe gestern mein ACE 2 BTU 550MB Ram mit youtube über eine Stunde gequält und hatte keine Probleme vorher mit der TMN wars meistens nach dem ersten Video schon vorbei und mein Handy hat sich aufgehängt.

gruss er1973

 

[JDfense]

Moin,

ist nur ein kleiner Denkansatz, mit Androids Partitionierung bin ich nicht so vertraut (Linux schon), aber könnte es sein, dass mit der PIT von MB4 der SWAP-Speicher vergrößert wurde und dir dadurch fast 1GB RAM angezeigt wird? Wäre für mich die einzig sinnvolle Erklärung. Daraufhin reserviert sich Jelly Bean seinen Speicher, einen Teil vielleicht im SWAP, einen anderen im richtigen RAM, was dazu führt, dass von den 768MB "original RAM" noch 624 MB übrig bleiben, weil JB den SWAP-Speicher füllt?

Würde auch folgender Rechnung entsprechen:

786MB (Gesamtspeicher) - 482MB (freier Speicher) = 304MB (von Jelly Bean reserviert, wenn keine Leaks geflasht wurden)
624MB (Leak-Freier-RAM) + 304MB (Jelly Bean RAM) = 928MB (entspricht ca. der RAM-Größe, die JDefense insgesamt angezeigt wird)

Nur so eine Idee

Interessante Idee. Der Swap müsste dann im internal Flash Speicher liegen oder? Vielleicht schauen alle 482er mal da hin, ob sie ein Swap-file finden.
Es erklärt aber nicht warum dieser Highmem-Bereich beim 482er nicht anläuft/scheitert(to low?)
Wenn das Absicht ist, dann hat Samsung vielleicht diesen Highmem rausgenommen, weil er das ROM instabil macht, aber das ist alles nur Spekulation, weil ich nicht genug darüber weiß, nach welchen Regeln Android JB den RAM nutzt. Vielleicht hat Samsung auch wirklich Probleme bekommen mit der ungewöhnlichen Mischung von 512 und 256er RAM-Bausteinen.
Jedenfalls führt der reguläre Weg von GB über Kies sicher zu 482MB mit abgeschaltetem Highmem.

JDfense

 

[Kenchi]

Das mit der Rechnung macht Sinn und auch die Annahme von JDfense könnte durchaus zutreffen. Aber wenn der Highmem wirklich auf Grund von Instabilität rausgenommen wurde, sollte ja nur das direkte flashen auf JB richtig sein.
Und wenn es noch zusätzlich ein SWAP gibt, die dann das hohe RAM ausmachen, ist es auch nicht verwunderlich, wenn es manchmal ein bisschen länger dauert. Da muss das System ja auf verschiedene Stellen schreiben, oder täusche ich mich da? (Bin zwar Linuxkundig aber nicht so sehr über Partitionierung)

Eine andere Frage: Wie sieht es bei euch mit dem Akku aus? Ich weiß nicht, ob meiner noch kalibriert werden muss aber ich habe das gerät eben angemacht und da waren dann schon binnen 15 Minuten 6 % weg, obwohl es nur da lag. Und ich habe keine Apps laufen, die Akku saugen. Ich habe sogar eine Großzahl über NoBloat deaktivert. Natürlich nur welche, bei denen es sicher ist
Alles sehr merkwürdig...

 

[uxx]

@ JDfense

Die Blockierungen entstanden bei mir wenn ich immer mal zwischendurch ein Video gestartet habe z.b. Zattoo, Selbstaufgenommenes Video mit der internen Kamera. Es kann aber wie gesagt einen ganzen Tag dauern, bis die ersten Freezer kommen.

 

[JDfense]

Ahh, da habe ich noch etwa 5 Stunden Zeit bis zum nervous breakdown.
Gestern habe ich aber schon mal einen ganzen Film übers Handy angesehen, um zu sehen, ob er mal hängt. War aber nichts.

Wir werden sehen.

JDfense