[AOSP/AOKP-KERNEL][ICS] *04.07.12* Fluxi XX.03-beta1[xxTweaker App, OTA, Touch CMWR]

[hellsgod]

Was steht im Titel? AOSP/AOKP - Also nicht für Sammy Roms.

hells

 

[androiduser44]

akkulaufzeit ist top
komme auf ca 6h display
3g permanent an
so hält der akku knapp 20h

aber wie gesagt, akkulaufzeit ist extremst von deinem nutzungsmuster abhängig

 

[masteru]

@hellsgod
na du bist ja ein ganz schlauer...

@androiduser44
super danke, welche rom benutzt du ?
und welche einstellungen hast du am kernel?

 

[ronnsen]

hab ne sammy rom und würde nur wechseln wenn die laufzeit besser wäre...

wenn dann wechselst du zu einer AOKP oder AOSP rom und kannst dann fluxis kernel genießen aber der läuft auf deiner sammy nicht.

 

[masteru]

das meinte ich auch mit wechseln !

 

[androiduser44]

@masteru
benutze den sakaschi mod update 2
habe die Taktrate auf max 800 und min 100

bisschen uv im unteren taktbereich sprich bei 100mhz und 200mhz, wobei natürlich die spannung bei 100mhz niedriger sein muss als bei 200mhz wenn du daraus ein nutzen ziehen willst
von uv im oberen taktbereich würde ich abraten
governor ist ondemand und scheduler deadline

 

[hellsgod]

Es ist nicht nur der Kernel für den Verbauch verantwortlich, sondern auch die Rom. Hier schneien immer wieder Leute mit Sammy rein und wollen diesen Kernel flashen, mir war nicht ganz klar, dass du ganz wechseln willst.

hells

 

[polford23]

Der Workaround ist sehr einfach: /META-INF/com/google/android/updater-script mit einem UNIX tauglichen Editor (Ultra-Edit, PSPad, Notepad++) bearbeiten und den oberen Teil mit den zu prüfenden Properties löschen:

Weg hiermit:

assert(getprop("ro.product.device") == "galaxys2" || getprop("ro.build.product") == "galaxys2" || 
       getprop("ro.product.device") == "GT-I9100" || getprop("ro.build.product") == "GT-I9100" || 
       getprop("ro.product.device") == "GT-I9100M" || getprop("ro.build.product") == "GT-I9100M" || 
       getprop("ro.product.device") == "GT-I9100P" || getprop("ro.build.product") == "GT-I9100P" || 
       getprop("ro.product.device") == "GT-I9100T" || getprop("ro.build.product") == "GT-I9100T");

Alle last_logs sehen gleich aus, das hilft nicht. Die Lösung liegt im CM Prüfcode. Leider kann ich gerade hierfür keine Zeit aufwenden - sorry.

Hab ich grad gemacht, bringt hier nix. Kann meine selbst compilierte CM9 Kang nicht flashen -> Status 7 :-(

EDIT: ok, geht doch, aber erst nachdem ich 1x Recovery rebooted hab.

boba

 

[Rockystrike]

AOSP/AOKP Kernel... kein Sammy.

Es läuft wieder alles wie gewohnt! Super Arbeit Fluxi, vielen Dank!

Gesendet von meinem GT-I9100 mit Tapatalk 2

 

[Mayday]

Komisch, OTA zeigt bei mir wieder keine Updates an.

 

[fluxi]

Hab ich grad gemacht, bringt hier nix. Kann meine selbst compilierte CM9 Kang nicht flashen -> Status 7 :-(

EDIT: ok, geht doch, aber erst nachdem ich 1x Recovery rebooted hab.

boba

Hoppla, der Beweis, warum ich 98% aller "Custom-Kernel" nicht auf 2 Kilometer an mein Gerät lassen würde, denn die Fähigkeit zu lesen ist zum Kompilieren eines Kernels nicht zwingend erforderlich.

Komisch, OTA zeigt bei mir wieder keine Updates an.

Mindestens Deine fünfte Beschwerde ohne Logs. Danke und Glückwunsch!

 

[simplymad]

Guten Morgen!

Muss mich bei dir entschuldigen, großer Fluxi. Das Datenproblem scheint bei CM9 zu liegen. Offenbar kommt das mit schnellen Wechseln nicht hinterher. Beim Umschalten von 2G auf 3G und andersrum streikt es, genau so verhält es sich auch bei schnellen Wechseln WLAN/Datenverbindung. WLAN selbst läuft fehlerfrei.

Ausgeschlossen habe ich inzwischen den Kernel (mehrere getestet) und auch das Modem (ebenfalls mehrere geflasht).

Dein Status 7 Problem scheint wohl momentan nicht das einzige zu sein, bei CM9. ;-)

So, nun aber zu meinem Kaffee. Hatte heute noch keinen.

EDIT: Das Problem tritt übrigens erst auf, wenn das SGS2 länger im Netz war. Vielleicht irgendein Buffer der voll läuft, man weiß es nicht.

Schönen Tag noch!

 

[fluxi]

Freut mich! Und dass einige mit den letzten CM Updates Probleme bekommen ("Status 7"). Das commit im CM repo ist schlicht fehlerhaft.

Bzgl. des WLAN Problems versuche mal Folgendes: Teste bitte folgende Werte, die Du mittels Root Explorer oder einer command shell oder ADB in "/proc/sys/vm/min_free_kbytes" schreibst

2048
4096
8192
16384

echo "DER_WERT" > /proc/sys/vm/min_free_kbytes

 

[mecss]

@Mayday,

Dann hast du irgend ein App, dass das verhindert. Vlt. eine Firewall a la Droidwall oder Privat-Security-App a la LBE?...

 

[simplymad]

Freut mich! Und dass einige mit den letzten CM Updates Probleme bekommen ("Status 7"). Das commit im CM repo ist schlicht fehlerhaft.

Bzgl. des WLAN Problems versuche mal Folgendes: Teste bitte folgende Werte, die Du mittels Root Explorer oder einer command shell oder ADB in echo "/proc/sys/vm/min_free_kbytes" schreibst

2048
4096
8192
16384

echo "DER_WERT" > /proc/sys/vm/min_free_kbytes

Jo, gerade mal mit 2048 gestartet. Ich gebe laut wenn ich was feststelle. Brauchst du vielleicht einen Log?

 

[mecss]

Deine Frage ist, so hoffe ich, rhetorischer Natur...

 

[simplymad]

Nein, er hat ja schon einen Log. Ich frage mich nur ob es sinnvoll ist, nach jeder Einstellung die ich vornehme auch einen Log zu erstellen. Er hat mir ja die Werte gegeben die ich in die min_free_kbytes schreiben soll. Keine Ahnung ob sowas im Log überhaupt ersichtlich ist. Wenn er nach jeder Einstellung einen Log will, bekommt er ihn. Wenn er zum Schluss einen Log will, von mir aus auch das.

 

[fluxi]

Logs sollten unmittelbar nach Auftreten des Fehlers erstellt werden. Bei FCs hilft es, kurz zu beschreiben, welche Aktionen vorher erfolgt sind.

Sobald ich Zeit dazu habe, schreibe ich alles auf. Aber Ihr wisst ja, wie es ist - das Produkt geht vor.

Jo, gerade mal mit 2048 gestartet. Ich gebe laut wenn ich was feststelle. Brauchst du vielleicht einen Log?

Zum eigentlichen Problem: Dieser Effekt tritt bei allen ROMs des i9100 auf, manchmal häufiger, manchmal seltener (in diesem Kernel), der Broadcom WIFI Treiber hat hier einen Knacks und Broadcom weiß das, kriegt es aber nicht hin. Diese Stelle im Patch adressiert das beobachtete Verhalten. Insgesamt wird 10 mal versucht, das Interface zu starten - ziemlich hacky, wie ich finde.

Teste mal die verschiedenen Cache-Werte und berichte, inwieweit sich das Verhalten ändert (verbessert oder verschlechtert). Lass Dir Zeit damit, keine Schnellschüsse.

 

[Mayday]

Mindestens Deine fünfte Beschwerde ohne Logs. Danke und Glückwunsch!

Danke.

Das ist mein 2ter Post was OTA angeht, eine Beschwerde sieht für mich anders aus, war nur eine Info.

Eine Log Datei ist vorhanden.

@Mayday,

Dann hast du irgend ein App, dass das verhindert. Vlt. eine Firewall a la Droidwall oder Privat-Security-App a la LBE?...

Ich habe nur LBE installiert, der Tweaker wird aber nicht geblockt.

Ist auch nicht schlimm, da ich dem manuellen Flashen gewachsen bin, wundert mich nur bißchen.

 

[fluxi]

Immer noch kein Log? Ohne Logs keine Verbesserung - schade. Also: Push the button!