[Kernel] Franco

[rageltus]

Hier ein neuer Kernel, den einige bestimmt schon kennen, der mich aber direkt überzeugt hat:

- immer aktuelle Bugfixes von Ezekeel
- Über Nacht im Flugmodus nur 1% Verlust der Batterie (bei mir



Forum bei XDA

8 November
* PMEM disabled as herring doesn't use it - this way we recover 12,5mb ram
* Ext4 special mounted on the source - more performance and don't need remounting init.d scripts
* Writeback settings now working correctly and are not overwritten by the ramdisk
* Minfree settings are now correctly set and are not overwritten by the ramdisk
* Thanks morfic for the lively discussions and ideas

6 November
* Latest deep_idle bugfix from Ezekeel
* Added Ezekeel's custom_voltage mod. For more info about it visit the respective thread. Yes it's compatible with SetCPU, maybe with Proton too, I didn't test it
* Added back BLD, touch wake and screen dimmer
* Improved CRC32 algorithm - it's used for many kernel functions
* CFS version: Cgroups: introduce timer slack subsystem - Provides a way of tasks grouping by timer slack value. This functionality is useful in mobile devices where certain background apps are attached to a cgroup and minimum wakeups are desired

3 November
* Latest deep idle bugfix from Ezekeel
* Offering two separated downloads, one CFS and another BFS. Don't ask me which one is better, try it and see, I'll be really mad if I get questions like that
* Idle_stats show 0 in every field - don't worry about that, it happens because of my cpu_idle 3.1 backport, but I assure you deep idle is working. Again I'm not answering questions like "WHY IS IDLE STATS 0?!?!? HALP PLZ".
* 'screenoff_maxfreq' is disabled by default. If you want that behavior write this in the terminal: echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/lazy/screenoff_maxfreq

2 November
* Newest deep idle bugfix from Ezekeel
* Reverted back to CFS because stock users had mounting problems with the sdcard and some users had data/wifi drops and I don't want that

1 November
* First and entirely BFS kernel with the newest 0.413 version
* Optimized the tunable BFS parameters for extra interactivity and smoothness
* More debugging disabled - I'm pretty sure 99% of the debugging flags are now disabled
* All the latest bugfixes and implementations from Ezekeel, including live_oc up to 150, lazy maxfrequency_screenoff enabled by default and all the other small fixes to ensure maximum stability
* Small changes to the lowmemorykiller
* Added optimized RWSEM algorithm
* Added some minor improvements and tweaks
* Sorry devs that wanted logcat, it's still a module because I suspect I'll have to update this build again with some extra fixes from Ezekeel in a very near future thus not making much sense to release two kernels now, one with logcat on and other with it off because that takes time to compile. If you desperatly need logcat go to my .config and change CONFIG_ANDROID_LOGGER=m to CONFIG_ANDROID_LOGGER=y and recompile it

27 October
* Latest deep idle and live oc bugfix from Ezekeel - should fix that extra battery drain reported by some users
* Changed lowmemorykiller.c - minfree settings already incorporated in the file. Settings kanged from morfic's tweak file, thanks
* Add cleancache - driver to cache clean pages
* Fixed ext4 disk write performance regression
* Small power management fix to back off suspend if repeated attempts fail - avoid continually trying to suspend in situations in which a driver is repeatedly rejecting suspend or a pending wakeup interrupt is not handled, burning CPU in the continuous suspend attempts
* Lib file added for the users where BLN didn't work
* Logcat module added inside /system/modules. If you want to use logcat just load the module with insmod

24 October
* BLX added again by default and patched up to the latest fix from Ezekeel
* Deep idle patched up to the latest fix from Ezekeel
* Live OC added and patched up to the latest fix from Ezekeel. To overclock you need to do this in the terminal or in an init.d file: echo 110 > /sys/class/misc/liveoc/oc_value. The 110 value means that both cpu frequency and bus frequency will be increased by 10%. You can increase this value as much as you want, as long as you increase the voltages otherwise the device won't handle it, but that's obvious.
* Changed dirty_writeback values from morfic to increase smoothness
* Overclock frequencies removed. The device is fast enough with 1000,800,400,200 and 100 frequencies. If you want to overclock use Live OC, it's enough to make it fly
* Conservative governor tweaked - smooth as butter
* Removed a ton of debugging shit
* Deadline I/O scheduler made default - after much testing it seems to produce the best and more regular results
* Swappiness disabled
* For more information visit my github, this are the most important changes

21 October
* Latest Deep idle bugfix from Ezekeel
* sched: disable GENTLE_FAIR_SLEEPERS
* Remove few obsolete governors
* BLN fix for MIUI users - now it should be propely set and full working
* Just 3 more tweaks:
PM QoS: Correct pr_debug() misuse and improve parameter checks
mmc: core: put eMMC in sleep (cmd5) mode before suspend
vmscan: prevent background aging of anon page in no swap system

19 October
* UV shit is fixed, SetCPU and Proton should work fine now
* Config_HZ increased to 1000 by request of an user
* Small tweak to VR
* Compiled with special Cflags from netarchy
* Calibration tweaks for touchscreen from netarchy

18 October
* Update cpu freq. to allow UV interface - you can modify the voltages on the fly going to /sys/devices/system/cpu/cpu0/cpufreq/UV_mV_table with an easy layout
* Auto BLN added again - it works now out of the box without the need of an extra app
* Add Lazy governor by Ezekeel
* config edited again, removed alot of shit options that are not needed at all - this way the kernel is even leaner
* cpu_idle backport from 3.1 - maybe helps with the BSOD problem
* Tweaked VR scheduler to work better for flash devices like our Nexus
* Ext4 tweaks
* A lot of USB tweaked code
* More fs tweaks to decreast CPU usage on unecessary shit
* More TCP/IP tweaks
* vfs_cache_pressure -> 25
* dirty_background_ratio -> 60
* dirty_ratio -> 90
* vm_swappiness -> 30
* Sysfs interface for deep_idle created by Ezekeel was added. If you want to disable deep_idle run this command: echo 0 > /sys/class/misc/deepidle/enabled
* Screen refresh rate increased to 65hz, everything should be even smoother (thanks morfic)
* If you want more detailed information about all the tweaks added you can visit my github

----------

* No more debugging shit in the kernel. No logcat, no dmesg, no debug_kernel etc etc, this shit is clean on that logging stuff that only consume CPU cycles in the background
* CFS scheduler tweaked with custom settings
* dirty_writeback value increased from 5*100 to 15*100, reducing unnecessary I/O activity, thus releasing a few CPU cycles
* Deep Idle mod by Ezekeel (latest version)
* Few patches to lowmemorykiller.c hopefully to optimize memory usage
* Add VR I/O scheduler and made default. A lot of performance gain comes from this one.
* Also enabled BFQ scheduler to be an option with no-frills
* init/calibrate.c port from 2.6.39. Better loops per jiffy calculations
* vfs_cache_pressure 100->50
* Add Stochastic Fair Blue (SFB) network scheduler and make it default. This is a network packet scheduler, should make internet usage a lot smoother
* Changed TCP_congestion scheduler to TCP_Veno. TCP Veno module is a new congestion control module to improve TCP performance over wireless networks. The key innovation in TCP Veno is the enhancement of TCP Reno/Sack congestion control algorithm by using the estimated state of a connection based on TCP Vegas. This scheme significantly reduces "blind" reduction of TCP window regardless of the cause of packet loss.
* Tiny RCU is the default RCU engine. More explanation on this RCU here RCU: The Bloatwatch Edition [LWN.net]
* Kernel compiled with -O2, meaning the code is more optimized instead of being compiled for size
* WiFi = PM_FAST in standby
* Optimized the config options for CFS Autogroup in the .config file, it should be perfect now
* Again more and more debugging disabled
* Obviously some minor changes and tweaking, but that can all be seen in my github below

Download

 

[4tticuz]

Danke für das Einstellen!

Da habe ich direkt eine Frage:
Ich habe den Kernel mit Brainmasters MIUI laufen.
Bei dieser MIUI ist ja No-frills CPU bei.
Zusätzlich habe ich mir noch SetCPU geladen.
Sollte ich zum OC vlt doch NSTools nehmen?
Und gibt es Probleme, wenn ich alle 3 Apps installiert habe?

Werde heute den Kernel mal untersuchen und die nächsten Tage in verschiedenen Modi fahren.

Bisher bin ich skeptisch, lasse mich aber gerne eines Besseren belehren.

 

[rageltus]

Also mit MIUI habe ich keine Erfahrung. Hier geht es auch nur um den Kernel selbst. NSTools nutze ich um den Kernel selbst einzustellen. Die Voltzahlen sind immer gleich. Egal ob du jetzt das über NSTools oder SetCPU einstellst.

Bzgl. MIUI gibt es einen eigenen Thread.

 

[WxK]

Danke für das Einstellen!

Da habe ich direkt eine Frage:
Ich habe den Kernel mit Brainmasters MIUI laufen.
Bei dieser MIUI ist ja No-frills CPU bei.
Zusätzlich habe ich mir noch SetCPU geladen.
Sollte ich zum OC vlt doch NSTools nehmen?
Und gibt es Probleme, wenn ich alle 3 Apps installiert habe?

Werde heute den Kernel mal untersuchen und die nächsten Tage in verschiedenen Modi fahren.

Bisher bin ich skeptisch, lasse mich aber gerne eines Besseren belehren.

Als guter Tip: Benutz nicht 2 Taktungs tools. schmeiß No-frills CPU runter. Setcpu ist besser. No-frills CPU ist mit drin weil es gratis ist.

 

[4tticuz]

Also mit MIUI habe ich keine Erfahrung. Hier geht es auch nur um den Kernel selbst. NSTools nutze ich um den Kernel selbst einzustellen. Die Voltzahlen sind immer gleich. Egal ob du jetzt das über NSTools oder SetCPU einstellst.

Bzgl. MIUI gibt es einen eigenen Thread.

Mir ging es ja auch eigentlich darum, welchen Tool ich benutzen soll.
Einmal davon abgesehen denke ich, dass eine Frage nach Kernel + CustomROM legitim ist.
Der kernel arbeitet ja nicht mit jeder ROM gleich gut / schlecht

 

[rageltus]

Aber vll lesen bei MIUI mehr leute mit wo den Kernel mit MIUI nutzen als hier . Darum meinte ich es gibt einen eigenen Thread..

 

[4tticuz]

Aber vll lesen bei MIUI mehr leute mit wo den Kernel mit MIUI nutzen als hier . Darum meinte ich es gibt einen eigenen Thread..

OK, geb ich Dir Recht

Andere (Franco's Kernel-bezogene Frage ):
Was muss ich beachten, wenn ich den kernel wechseln möchte?

 

[rageltus]

Hmm ich beachte nicht viel außer, den alten Kernel wo läuft nochmals parat zu haben, den Dalvik-cache zu löschen, den cache zu löschen (ACHTUNG: Nicht die userdaten sondern nur der cache) und dann Fix Permissions auszuführen. Lief bei mir immer ohne Probleme von statten. Egal welcher Kernel.

 

[flying fox]

.....
Bei dieser MIUI ist ja No-frills CPU bei.
Zusätzlich habe ich mir noch SetCPU geladen.
Sollte ich zum OC vlt doch NSTools nehmen?
Und gibt es Probleme, wenn ich alle 3 Apps installiert habe?.....

Probleme gibt es keine, nur verschwendest du unnötig Ressourcen.

NSTools ist perfekt für diesen Kernel (wenn du LiveOC, Deep Idle etc nutzt). OC ist mit diesem Tool nicht möglich, aber durch LiveOC meiner Meinung nach auch nicht mehr notwendig bzw sinnvoll. Da du mit NSTolls keine Taktgrenzen setzen kannst, brauchst du etwas wie SetCPU, sofern du dies tun möchtest. Ich habe es noch laufen, da ich gerne mal auf 800Mhz runter gehe, dzt teste ich noch 1000Mhz (mit LiveOC 1100), da unter den Mods von Ezekeel es für die Akku-Laufzeit angeblich keinen wirklichen Nutzen mehr bringt, die CPU zu untertakten..

Zum Kernel selbst. Bei mir läuft die BFS-Version. Er ist stabil, keine Reboots bisher (seit über 1 Woche), schnell (bin kein Gamer, aber für alles andere ist "flott" kein Ausdruck) und mit guter Auswirkung auf die Akku-Laufzeit. Nach mehreren kompletten Ladezyklen heute das erste Mal genauer hingesehen. Heute um 12h30 weg von der Steckdose mit 99%, jetzt nach 5h mit normaler Nutzung noch 93%. Zugegeben, das heisst jetzt nicht viel, ich muss bis morgen abwarten. Aber für gewöhnlich komme ich keine 24h durch, dass dürfte sich mit dem Franco 11/8 geändert haben.

Meine Settings:
CPU 440/1100 Mhz
Live OC 110
Deep Idle aktiviert mit maxfreq
Arm Volt 1250/1155/1000/900/900
Int Volt stock

Damit läuft es für mich perfekt......

 

[mike.bee]

Habe bisher noch MKatr1x v10 am laufen. Soll ich umsteigen? XD Was hat Matr1x, was Franco nicht hat?

 

[flying fox]

Habe bisher noch MKatr1x v10 am laufen. Soll ich umsteigen? XD Was hat Matr1x, was Franco nicht hat?

Franco geht "nur" bis 1GHz. Wenn du dein Nexus übertakten willst (also nicht liveOC), dann geht das nur mit dem Matr1x (bzw mit jedem anderen Kernel, der mehr Takt "bietet". Und wenn du mit ihm zufrieden bist, brauchst du ja nicht wechseln; wenn dein System läuft, dann läuft es...

 

[brainmaster]

Als guter Tip: Benutz nicht 2 Taktungs tools. schmeiß No-frills CPU runter. Setcpu ist besser. No-frills CPU ist mit drin weil es gratis ist.

Falsch. SetCPU ist auch gratis für XDA user.

NoFrills ist in meinem ROM dabei weil die app viel weniger RAM verbraucht als SetCPU.

 

[WxK]

Eben nur für die XDA user. Ich weiß ja nicht wer XDA user ist^^

SetCPU bietet aber mehr als No-frills CPU von daher bleibt es Geschmacksache!

 

[brainmaster]

Eben nur für die XDA user. Ich weiß ja nicht wer XDA user ist^^

SetCPU bietet aber mehr als No-frills CPU von daher bleibt es Geschmacksache!

Mein ROM ist hosted bei der XDA, also hätte ich auch integrieren können.

Aber, es ist die Geschmackssache.

 

[flying fox]

Zur Info:
Unter diesem Kernel weiß ich nicht, wie man die Aktivität von Deep Idle überprüfen kann. Franco habe irgendwelche Dateien (?) beseitigt, die die Angabe der Idle States ermögliclhen. Sei es per Terminal Emulater oder per NSTools, Zeitangaben für Idle, Deep Idle Top On und Deep Idle Top Off zeigen immer 0ms.

Nun gibt es bei Manchen einen "Didle-Cam-Bug", unabhängig vom Kernel. Obwohl Deep Idle aktiviert sein soll, dh im script auf "enabled" steht, ist er inaktiv. Das hat nichts mit diesem Kernel zu tun! Durch Ein- und Ausschalten der System-Kamera soll sich Deep Idle, sofern der Bug besteht, dann tatsächlich erst aktivieren. Um das zu überprüfen habe ich mir vorrübergehend Ezekeel´s Kernel geflasht, unter dem ich die Deep Idle States einsehen konnte. Auch hier waren alle Werte auf 0ms. Die System Kamera hatte ich deinstalliert, den Test habe ich mit Brainmaster´s implementierter Kamera-App gemacht: Ein, 20s warten, aus. Die Werte blieben auf 0ms (dachte eigentlich, es sei egal, mit welcher Kamera-App, vielleicht benötigt es dazu aber wirklich die "System-Kamera".....). Auch wenn das Ein-/Ausschalten der Kamera Deep Idle aktiviert, dann nur bis zum nächsten Reboot!

Nun habe ich bei XDA gelesen, dass dieser Bug in Zusammenhang mit der App Google-Talk stehe, und zwar mit der Version 1.3. Davon gäbe es zwei, eine mit Video, eine ohne. Verantwortlich für den Bug sei die Version mit Videofunktion. Egal, per script manager habe ich Google Talk deinstalliert - und siehe da, bei "Deep Idle Top Off" erscheinen ms-Einträge (unter Ezekeel´s kernel) als Zeichen, dass Deep Idle nun funktioniert. Habe dann den Franco-Kernel gleich zurückgeflasht.

Fazit:
zumindest bei mir scheint tatsächlich "Google App" über den Weg der Kamera Deep Idle verhindert zu haben. Die Deinstallation hat den "Bug" beseitigt". Das hat NICHTS mit diesem Kernel zu tun, nur hatte ich eben keine Möglichkeit gefunden, dies unter Francos Kernel unter die Lupe zu nehmen. Selbstverständlich bleibt einmal der Franco

Quelle: XDA

Do you have google talk installed?
Try uninstall it.
Several days ago i noticed in logcat. google talk request for camera on boot, after i remove google talk the problem dissappear. Deepidle always on after reboot.....

I checked my talk version and it is the one without video chat and it says version 1.3. With this version I don't have the "didle-cam bug".

After that I've installed the talk version with video chat from here. This version also says 1.3 and I have the "didle-cam bug".

Das Problem liegt also offenbar nicht an der ROM, nicht am Kernel, sondern an Google Talk.

 

[4tticuz]

Danke für den Hinweis!
Ich habe auch zur Zeit Francos Kernel drauf und bin bisher sehr zufrieden.
Habe nach 1d12h33min noch 61% und habe das Telefon normal benutzt (daheim WLAN, unterwegs 2g, immer sync an, zwischendurch apps geladen, telefoniert, im+, sms, gesurft und Ne folge dexter gesehen).

Hatte grade mit NSTools deep idle aktiviert und musste feststellen, dass nach einer gewissen Zeit bei den stats 0ms stand.
Jetzt weiss ich nicht, ob ich wechseln soll, aber wahrscheinlich ist, dass ich morgen diesen Kernel zu ende teste und dann der nächste kommt (wahrscheinlich der von ezekel himself).

Mal gucken, was die Messungen ergeben!

 

[frajo]

Hat jemand Erkenntnisse darüber, ob die CFS- oder die BFS-Variante mehr Akku braucht?

 

[flying fox]

......Hatte grade mit NSTools deep idle aktiviert und musste feststellen, dass nach einer gewissen Zeit bei den stats 0ms stand.
...

Einen Post über deinem steht alles drin . Der Franco zeigt immer 0ms an , egal ob Deep Idle aktiviert ist oder nicht.

 

[4tticuz]

Einen Post über deinem steht alles drin . Der Franco zeigt immer 0ms an , egal ob Deep Idle aktiviert ist oder nicht.

Ok, dann hoffe ich, dass bald die Kernel mit dem NSTool "vernünftig" ausgelesen werden können und ich nur noch ein Tool für die Kernelsteuerung benötige

 

[flying fox]

Ok, dann hoffe ich, dass bald die Kernel mit dem NSTool "vernünftig" ausgelesen werden können und ich nur noch ein Tool für die Kernelsteuerung benötige

Franco hat für Testzwecke ein "Test-Update" bereitgestellt. Änderungen sind noch nicht bekannt, die Idle States können damit jedenfalls ausgelesen werden: franco.Kernel09112011-cfs-test

Aber nicht vergessen, "nur" ein Test-Kernel