Overclock Patch and update.zip - Droid Eris Android Development

Overclock Patch and update.zip - Droid Eris Android Development

READ THE NOTES ON SETCPU BELOW BEFORE INSTALLING!!!
I've just spent the last few days bothering to understand the Eris cpu frequency manipulation in the recently released kernel. I know a few people have already released kernels and ROMs with an overclock-enabled kernel based upon the work done for the Hero, but there are some additional complications with this one.
TECHNICAL INFO FOR GEEKS
There are 4 "clock sources" on this thing, at least. They're called txc0 (the base clock), mpll (modem phase lock loop), gpll (global PLL), and bpll0 (backup PLL zero). The processor can handle a bpll1 as well, but if it's there, it's nearly completely unconfigured. They run at these frequencies:
txc0: 19200kHz
mpll: 245760kHz
gpll: 960000kHz
bpll0: 1056000kHz
The way our cpu handles changing frequencies (at least by default) is to select between these 4 sources, and apply a divider of 1 through 16 to it. There are a number of frequencies that the kernel steps through when changing between frequencies, and they're all specified as source/divider conbinations in the acpuclock-arm11.c file in the kernel, but the only ones exported to the cpufreq module (the thing that setcpu uses) are the following (these are the same frequencies you'll see in SetCPU if you select msm7k turbo, aka Hero):
19200 (txc0)
122880 (mpll/5)
160000 (gpll/6)
245760 (mpll)
480000 (gpll/2)
528000 (bpll0/2)
If you're particularly math-savvy, you'll realize that there's no way to get any frequencies between 528MHz and 960MHz using this whole "source/divider" method. It's been tried, by myself and others, to clock our cpu at 960MHz...it simply doesn't work, sorry guys.
So, someone really bright figured out that you can actually change the configuration of bpll0 itself on the Hero, by writing a multiplier (of the txc0 frequency) to a magic location on the board. This way, we could set the bpll0 source to whatever base frequency we wanted! That worked quite well for the Hero -- set the bpll0 source to the cpu frequency we wanted, and remove the divider, and you get any multiple of 19.2MHz that you'd like.
In the overly complicated (and redundant) table of frequencies in the acpuclock-arm11.c source code, there's an AHB frequency field, and an AHB clock divider. The AHB bus is like the PCI bus on a computer -- it runs wifi, usb, and things like that. The frequency listed in the table is completely for humans, as the code doesn't use it anywhere. However, the divider is applied to the *CPU frequency*, and the max it can be is 4 (it's only a 2-bit field, 0, 1, 2, or 3 -- add one to the value to get the divider value). At 528MHz cpu speed, the bus is at 132MHz with the max multiplier, and there's no way to overclock the CPU without also overclocking the AHB bus. C'est la vie.
On the Eris, there are further issues. The first of which is PerfLock.
Even before trying of overclock, I'm sure some of you installed setcpu and noticed that you could set the sliders to anything you wanted, and the cpu ignored you. It would stay at 480min/528max, no matter what, while the screen was on. (It actually went to 245.76min/254.76max while the screen was off, but that's harder to notice.) This is because the lovely people at HTC were trying to conserve power by scaling down the cpu when you weren't using the phone, and still have it be responsive when you were actually fiddling with it. In order to have setcpu work, we need to disable the perflock hooks into the cpufreq module.
The second issue is that bpll0 is used by something other than the CPU. I don't know what, but I do know that setting the base clock to much less than 700MHz makes it mighty unstable, and that it gets even *more* unstable as you *decrease* the frequency, which means that whatever else is using that source really doesn't like to get underclocked. So, we have a balancing game: The bpll0 source needs to be high enough that we're not severely underclocking the other hardware, and low enough that we're not cooking the CPU.
I tried two ways around this. First, I decided to become really bright myself, and I found the config locations for the gpll and mpll sources as well, and tried using the gpll source instead of bpll0. I did manage to clock gpll up and down, but anything other than 960MHz seemed very unstable. I suspect that a lot of the phone hardware is based on that source -- it is called "global", after all. The second way was to overclock the bpll0 source and keep the divider of 2, instead of underclocking it. That actually worked, but became unstable when the frequency got much higher than 650. So, I reverted to using bpll0 at 768 with no divider, which has been very stable thus far.
I tried, in fact, every multiple of 19.2 between 528 and 864. The sweet spot of stability is at 768, and anything higher or lower rapidly loses stability.
The next issue, also related to power saving, is the power collapse stepping. The kernel actually steps the kernel down to "idle", consuming the least amount of power, by bringing the cpu all the way down to 19.2MHz when idle. For every jump of more than 256MHz, up or down, the phone goes through this series of frequency jumps specified by the "up" and "down" fields of the frequency table, which are just indexes into the same table for the next frequency in the sequence. Existing patches that simply copy the 528 line as a whole and alter only the frequency and divider will lead to problems in two ways: First, if you try to jump from 480 to, say, 768, it will fail. The kernel will tell you that it's now running at 768, but it will actually still be running at 480, because the "up" field of the 480 entry is invalid and the difference is greater than 256. The 528 frequency is within 256 of 480, so there was no reason to put a valid entry there. This means that if you're using the ondemand governor, *sometimes* it will successfully overclock, and sometimes it won't. I observed this with my own testing, both in performance tests and in the debug logs for the kernel. Second, if you try to collapse *down* from 768, the "down" field of the 528 entry brings it down to 352, which is going to be more than 256, which causes the CPU to become unstable.
With the existing patches, it would just *leave* the bpll0 multiplier at the lower value, meaning that during power collapse, the intermediate frequencies would be different than the driver suspected, and larger than 256MHz of a jump as well, making the phone significantly less stable. It's just bad all around.
To make matters even more complicated, if you actually get rid of the perflock hooks, the cpufreq module defaults to setting the min and max to the lowest and highest available frequencies, causing major mayhem if your phone can't actually handle the overclocked frequencies that are enabled in the kernel.
WHAT I'VE DONE
This patch (attached), when applied to the Eris 2.1 kernel source from HTC, with the config taken directly from the leaked rom of the phone, will give you a kernel that will obey setcpu, will set the default min/max upon boot to 245.76/528 so you're not overclocking by default, enables the "auto" mode of setcpu, adds a frequency of 768MHz, and fixes up the step up/down fields of the table to make the ondemand and power collapse dynamic frequency steppings work consistently and as expected (by restoring the correct PLL multiplier for every frequency, adding correct steppings to 528, 480, and 768 entries, and being sure increase divider and decrease multipliers before decreasing dividers or increasing multipliers). Oh, and I enabled the netfilter module required by DroidWall, because about five million people asked me to.
Because I'm nice and a lot of people don't like compiling their own kernels, I've also attached a flashable update.zip that flashes a new boot.img (ramdisk+kernel) and installs the corresponding wifi driver.
I get a 50% increase in Linpack scores with the below patch. (I'm running Ivan's 0.8T2 right now, went from 2.2 at 528MHz to 3.3 at 768MHz.)
EDITED TO ADD:
A number of people have asked what my SetCPU profiles look like. They look like this:
Default: 480/768 (I have it clock down to 480 instead of 528 because 480 actually uses a lower voltage.)
Standby: 160/245 (I like battery life. It takes a while to show me who's calling, though, when it rings while in standby.)
Failsafe: 40C/245/245 (40 degrees is probably too hot. I want to stop it before it melts, which would be around 50 degrees.)
UPDATE: V2
So, 768MHz is the sweet spot on *my* phone, but apparently not all are created equal. I've added two more frequencies, 604.8MHz (overclocking bpll0 to 1209.6MHz and dividing by 2) and 710.4MHz (underclocking bpll0 to 710.4MHz). There's a notable gap between 604.8 and 710.4 to avoid the particularly unstable bpll0 settings. Everyone's phone seems to be able to handle 710, though. Everyone should be able to safely scale up and down through these frequencies.
UPDATE: V3
I've added every frequency step between 710.4MHz and 864MHz in this one, skipping over the unstable frequencies between 604.8MHz and 710.4MHz. On my own phone, I started getting really odd performance issues at 806.4MHz, and it insta-crashed at 844.8MHz. It's worth noting that all frequencies above 768 have an additional power collapse frequency to step through -- I noticed some *average* performance decreases, even though the fastest linpack runs were still faster than at 768MHz.
HOW TO USE
If you're just wanting to run the kernel and enable overclocking, do the following:
Install SetCPU, if you haven't already. It's available here on XDA for free and for $0.99 on the Market.
In SetCPU, choose the "HTC Hero/Tattoo [MSM7k Turbo]" option from the device selection menu. The CPU will happily ignore you, but setting it to this means that you won't enter a reboot loop after patching when SetCPU starts and overclocks your CPU entirely too much.
Make sure the "Set on Boot" option is unchecked, until you're absolutely certain that the settings you've got won't freeze your phone. Also, turn off profiles.
Flash the latest kernel-overclock-update-v*.zip below, using your favorite method, and boot your phone. Note that this kernel update will not overclock your phone until SetCPU tells it to -- the default policy is 245.76MHz min, 528MHz max, ondemand.
Start SetCPU, hit menu, and go to device selection. This time, select "Autodetect Settings". Make sure that the FIRST thing you do after device selection is move the max slider down to 528, so your phone doesn't insta-lock on you when SetCPU applies settings.
Change the governor to "performance" (which means it will always use the highest frequency in the range), and start incrementing the max up from 528MHz, one step at a time, releasing your finger each step (SetCPU applies the change when you let go of the slider), until your phone freezes.
Remember the bit about not checking the "Set at Boot" option? This is why. Reboot your phone (this will probably involve pulling the battery, if the phone didn't reboot on its own), and start SetCPU again. SetCPU very nicely shows you the last settings you saved, but does not apply them, which is nice because those settings will lock your phone. Lower the max setting to something that won't lock your phone, put the governor back to "ondemand", and set up profiles how you like.
If you would like to add this kernel to your ROM, do the following:
Create a boot.img for your rom, using the "zImage" file in the latest kernel-overclock-zimage-v*.zip below. You'll likely need mkbootimg for this. If you're making your own ROMs, you should already know everything needed for this except perhaps that you need to use the "--base 0x11200000" option.
Make sure your ROM places the wlan.ko file from the same zipfile at "/system/lib/modules/wlan.ko".
If you'd like to apply this patch and compile the kernel for yourself, do the following:
Download and extract the latest Eris kernel source. This patch is applied against the source distributed as "desirec_2.6.29_8a03cb9a.tar.bz2". Google is your friend for finding it.
Install the Android NDK, if you haven't already. I recommend version r3. Make sure that "build/prebuilt/linux-x86/arm-eabi-4.4.0/bin" under the top-level NDK directory is in your PATH, or the kernel build won't be able to find your compilers.
In the top-level directory of the kernel source, run "make desirec_defconfig". This will generate the .config file used to configure the kernel.
Download the latest "kernel-overclock-v*.patch.txt" file below, to the top-level kernel source directory. (It actually doesn't matter where you download it, just be sure to specify the correct path to it in the command below.)
In the top-level kernel source directory, run "patch -p1 < kernel-overclock-v*.patch.txt". (I assume here that you have the "patch" utility. If not, go get it.)
Still in the top-level kernel source directory, run "make". When all is said and done, you'll have the compiled kernel at "arch/arm/boot/zImage".
Get the wlan.ko driver source. Easiest way is to install git and run "git clone git://android.git.kernel.org/platform/system/wlan/ti.git" in the directory you'd like to download it to.
Change to the sta_dk_4_0_4_32 directory under the wlan.ko source.
Set the KERNEL_DIR environment variable to the path to your top-level kernel source from above, and run "make". When all is said and done, the wlan.ko module will be in the same directory.
V1 RELEASE FILES:
eris21-overclock-v1.patch.txt - patch for the kernel source code. To apply, untar the kernel source, run "make desirec_defconfig", then apply the patch (usually "patch -p1 < eris21-overclock.patch.txt"). Modify how you like and build.
kernel-overclock-zimage-v1.zip - zip containing the the kernel itself and the wlan.ko module, for addition to other ROMs.
V2 RELEASE FILES
eris21-overclock-v2.patch.txt - patch for the kernel source code. To apply, untar the kernel source, run "make desirec_defconfig", then apply the patch (usually "patch -p1 < eris21-overclock.patch.txt"). Modify how you like and build.
kernel-overclock-zimage-v2.zip - non-flashable zip containing the the kernel itself and wlan.ko module, for addition to other ROMs.
V3 RELEASE FILES
eris21-overclock-v3.patch.txt - patch for the kernel source code. To apply, untar the kernel source, run "make desirec_defconfig", then apply the patch (usually "patch -p1 < eris21-overclock.patch.txt"). Modify how you like and build.
kernel-overclock-update-v3.zip - flashable update.zip to install boot.img containing the built OC kernel and corresponding wifi module.
kernel-overclock-zimage-v3.zip - non-flashable zip containing the the kernel itself and wlan.ko module, for addition to other ROMs.
NOTES ON SETCPU
SetCPU doesn't actually set parameters until you make a change, and it will default to min/max at 19.2/864, which is clearly going to crash on every Eris we've tried. When you flash this, be sure to do the following, or it's your own darn fault if you get stuck in a reboot loop!
Clear out your setcpu settings before you flash. This means deleting the file /data/data/com.mhuang.overclocking/shared_prefs/setcpu.xml .
Select "Autodetect" on the device selection screen
Make sure that SetCPU is not set to start at boot, until you know you've found settings that won't freeze your phone on boot.
Make sure that the first thing you set is to move the max down to a value you know is stable. If it's your first time, set it to 528 and increment up from there.
The "performance" governor is like "always use the highest frequency of the range". It's useful for testing.

kick arse.

Pretty awesome will be checking it out on wifes phone. I think after reading all of that I personally feel smarter good work.

Thank You.
There is a reason those of us who don't post much have an enormous amount of respect for you.
This is it....
Your contributions have added more then most people will ever know.

thanks man

mad props zan man!

you are awesome.
Thank you so much!

Thanks man .......

WOW. I'll just echo the sentiment. I feel much smarter now.

After using ur update.zip over v17.zip now im getting 5.15 MFLOPS and 2658ms at 768MHz and thats with LWP running in the background of the n1 launcher

Thank you very much for enabling Netfilter modules for Droidwall. I been looking for a rom that supports this feature for Eris for a while. Nice work on OC too.

Thanks again! Zanfur you are da man!

great info. thanks for all your work you put in here. im great with computer, and i learned a LOT from that.
i really wish xda had a thanks button.

Can I flash this overtop of the Evil Eris 2.01 update?

carpsworld said:
Can I flash this overtop of the Evil Eris 2.01 update?
Click to expand...
Click to collapse
I expect so. I'd ask Framework about that directly though. You can always nandroid backup and try it... ;-)

zanfur said:
I expect so. I'd ask Framework about that directly though. You can always nandroid backup and try it... ;-)
Click to expand...
Click to collapse
I just tried that. So far so good. Benchmark numbers have imporved since flashing the update, but that could just be the 768MHz versus the 710MHz difference.

Installed over top of Evil Eris 2.01 update. It did not work. Stuck at boot screen.

g00gl3 said:
I just tried that. So far so good. Benchmark numbers have imporved since flashing the update, but that could just be the 768MHz versus the 710MHz difference.
Click to expand...
Click to collapse
How long did it take for you reboot. Which file did you use from the initial post?

carpsworld said:
How long did it take for you reboot. Which file did you use from the initial post?
Click to expand...
Click to collapse
It was actually very quick, not like when installing a new rom. I used the .zip file in the first post. Always remeber to nandroid backup just in case...
I would recommend downloading the file again and try to flash it again. Just restore back to your backup from before this attempt and give it another shot.

Now my nan backup isn't working either...ugh.

Related

(CM7/MIUI) Screenstate, Governor and Threshold Control Script

Hi Folks,
For those who are interested, I have modified the 90screenstate_scaling script used in Zach's (and now Glitch's) kernel for use with other CM7 compatible kernels. The aim is to create a very simple script that can easily be read, modified and improved upon by non-coders, such as myself.
I have retained only the code that will read the screen state, set the governor appropriately and set the scaling threshold, giving users complete control over the scheduling behavior of their CM compatible kernel.
I am not a coder and all credit goes to FloHimself and zacharius.maladroit for the original content. all I have done is (hopefully) simplify the script and make it easy for non-specialists to read.
If you would like to try it out, copy the script in to /system/etc/init.d and modify the values to your liking. If you are already on Zach's kernel there is nothing new here, as you already have this script.
The script currently includes kernel defaults from Glitch for the smartass governor, from Zach for the conservative and ondemand governors, a few experimental settings, and of course, the ability to modify them yourself.
If you add anything or make any modifications (particularly in relation to your specific usage pattern) you would like to share, please post them and I will update this thread. If you make modifications, comment them appropriately and explain your usage pattern for which the settings work best so that people know if it would work for them.
The experimental conservative settings that I have made (that are currently in use on Glitch kernel) for the screen off state are designed to aggressively keep the frequency very low, almost like a 100mhz frequency cap, while still allowing them to scale up under considerable load. They are (hopefully) ideal for background screen off behaviour such as listening to music, exercise applications or aggressive sync and push/pull email behavior (like in an office).
The experimental smartass settings are designed to test the hypothesis that quick downscaling may cause as many lags as as slow scaling up behavior. The goal is to create a more linearly scaling version of smartass which is slower to upscale or downscale (only a matter of milliseconds difference). These are still under testing.
With one of the main reasons for using smartass as a single governor, the min/max frequencies for the screen on/off state no longer applicable with the governor changing in relation to the screen state, I have moved to ondemand settings, which may have battery implication while the screen is on, but they are VERY smooth.

*subscribes*
we could probably make conservative governor more aggressive
with the settings that laststufo used on his kernel but I'm not sure if it would scaled up fast enough if you used e.g. some DSP settings on sound while the screen is off
worth as shot
if I don't forget it - I'll post the settings later

Subscribes too
I like the idea and the simplicity of this. And with Zach's help, also known as "F*ckin scripts master" (almost a private joke ), it can only be great.

I'm a big fan of simple, though as a user of Arch Linux on the desktop I have no choice (BSD style init scripts a boot - beautiful simplicity)!
It's great you lads are watching this! Hopefully the thread will grow in to something, even if it is just an sandbox for users to experiment with the settings they prefer. If nothing else, hopefully you guys get some useful info!

I just added a bit of an experimental version that moves away from the default smartass values.
I am hypothesizing that the very accasional lags in the smartass governor might be related to the governor scaling down too fast, rather than it not scaling up fast enough.
I changed the default down threshold from 40 to 35 and the default up threshold from 60 to 65. Hopefully this will scale up and down a little more linearly and this will make the GUI even smoother. I am still testing this theory at the moment, but thought I might post it (on the first post) if anyone wanted to have a go.

well.heeled.man,
you need to test your conservative settings while the screen is on
they're way too aggressive (at least the up threshold, down threshold may be ok)
also the freq_step at 10% should be at least at 15%
if we compare it with laststufo's kernel (he almost had 100 MHz steps everywhere: 100, 200, 400, 600, 800, 900, 1000 MHz)
so that needs to be compensated to get smoother & similar behavior
I'll take a look & see how the new smartass settings work out
my new conservative settings are:
echo "76" > /sys/devices/system/cpu/cpufreq/conservative/up_threshold # 50 # 76 # 76
echo "30" > /sys/devices/system/cpu/cpufreq/conservative/down_threshold # 35 # 12 # 30 (higher will lead to noticable lags) # 35
echo "15" > /sys/devices/system/cpu/cpufreq/conservative/freq_step # more aggressive ramping up (50)
this currently keeps the cpu between 100-200 MHz while playing MP3s for me (screen off) - mostly 200 afaik right now
but I'll try your conservative settings, too, when I find time - let's see how they are in terms of "smoothness" (I'm sure they're not too usable with the GUI but could be great for background tasks while the screen is off)

Hi Zach, indeed, I would say that the conservative settings are completely unusable with the screen on. I would not recommend these with the screen on.
However, with music (DSP manager too) GPS and Cardio Trainer all running (my cycle home), it seems to work fine (screen off). Every km, Cardio trainer speaks the time taken over the music (two audio streams). With many kernels this becomes slow, or slurred, but sounds perfect with these settings.

well.heeled.man said:
Hi Zach, indeed, I would say that the conservative settings are completely unusable with the screen on. I would not recommend these with the screen on.
However, with music (DSP manager too) GPS and Cardio Trainer all running (my cycle home), it seems to work fine (screen off). Every km, Cardio trainer speaks the time taken over the music (two audio streams). With many kernels this becomes slow, or slurred, but sounds perfect with these settings.
Click to expand...
Click to collapse
awesome !
so it still raises the frequency when needed ?
100 -> 200 (or more)
you checked via e.g. CPU Spy ?
thanks !

Yes, it still goes up when needed (confirmed via CPU Spy), but it needs to be really pushed. It seems like good behaviour in the screen off state.
EDIT: something in the region of a 66%/33% 100/200mhz split at these settings.

I am struggling to confirm that my settings are being applied as I would like in the screen off state. I can read off the values in /sys/devices/system/cpu(/cpu0)/cpufreq/conservative if I manually set conservative in Pimp My CPU with the screen on, but the behaviour seems at odds with the values i.e. not as laggy as one would suspect.

As (a variation of) this script are now used in Glitch's too, I have changed the comments to allow people to very easily see which settings are from kernel devs (which should probably be left alone should you wish to return to their defaults) and experimental settings (which I would suggest you change, if you change any). If you want to use parts of it in Zach's, I would suggest cutting and pasting the experimental part into the appropriate part of Zach's script as overwriting any part of it would remove much of his additional functionality.

This is great guys - thanks for this

With one of the main reasons for using smartass as a single governor, the min/max frequencies for the screen on/off state, no longer applicable with the governor changing in relation to the screen state, I have moved to ondemand settings by default. This may have battery implication while the screen is on, but they are VERY smooth.

wrong spot

screenstate_scaling_V49.zip
that's the current version of my screenstate_scaling script that I offer as an option with Neo 17 r7
most of the stuff moved into the S98system_tweak script that now is shipped with the kernel

[Q] System Tuner Settings

You can search all you want and still come up short, I'm trying to use system tuner to change the cpu and gpu settings and I cant find any help on how to use this app. Im running the latest Kaos Droid rom for 4.1.2, the latest Motley kernel and twrp, props to all developers:good:. Im looking for what the optimal settings are and how to use system tuner to change them. Can someone tell me or show me the right thread that can help? Im not sure what the min/max cpu settings should be and I cant seem to find where to change the gpu settings. We are all noobs at some point. I just want to beef my nexus up a little, nothing crazy.

aww for real?

I wouldn't use system tuner for this because it doesn't have the ability to change the GPU speed. I'd recommend TricksterMOD which is available here for free. Depending on your kernel (not sure if motley's kernel has configurable GPU now, it didn't when I used it) you can change different settings. It is personally up to you how you want to configure your device and change things depending on how it runs. Anyway, I'll give you an idea of my settings that I have changed.
CPU - Governor is Interactive (my kernels default but another alternative would be ondemand) running @ 102mhz min - 1600mhz max
IO - Governor is deadline (again default but imo the only one you should use) with cache at 1024.
GPU - 600mhz
VOLTAGES - My kernels defaults.
Make sure that you set the settings to be applied at boot (I use a delay of 1 because it didn't seem to apply without it) and also make sure your kernel has the powerHAL fix included, or else (in the case of trinity kernel) you will need to download this file (this is for Android 4.2.x). This will allow your CPU overclock to stick and not be reset to stock.
Hopefully this helps! But again, just play around with your frequency's and maybe look into voltage tweaking to get your personal balance between performance and power consumption. And if you are going for performance, I'd look at turning off fsync and using the ext4 mount script to boost your I/O dramatically (this will result in things such as faster app installs)

smt8544 thanks alot man! now I can start somewhere, I didnt wanna do anything stupid without some knowledge, I appreciate it!

CPU governor tuunables on stock and custom kernels.

Hi.
I'm running stock 6.0.1 ROM with latest squid kernel and I'm having problem with hispeed_freq settings, when I choose a desired frequency it won't stick to that, it always reverts to 1459200MHz. I followed a guide for interactive governor from http://forum.xda-developers.com/nexus-5x/general/guide-advanced-interactive-governor-t3269557/post64279960#post64279960 and the results are great except when hispeed_freq starts to screw itself up, the big CPU is then always stuck on 1459200MHz frequency which destroys the purpose of the guide. It happens also on stock based custom roms and that probably means it is ROM related. The same happens on stock and ultra kernels, the weird part is that it somehow worked normally on stock 6.0 and squid kernel even though not from the day one. Any ideas how to make hispeed_freq to stick to 533333MHz?
http://imgur.com/SS1ZWaf
EDIT: title should be CPU governor tunables on stock and custom kernels problem. My keyboard is dying.

ViperX85 said:
Hi.
I'm running stock 6.0.1 ROM with latest squid kernel and I'm having problem with hispeed_freq settings, when I choose a desired frequency it won't stick to that, it always reverts to 1459200MHz. I followed a guide for interactive governor from http://forum.xda-developers.com/nexus-5x/general/guide-advanced-interactive-governor-t3269557/post64279960#post64279960 and the results are great except when hispeed_freq starts to screw itself up, the big CPU is then always stuck on 1459200MHz frequency which destroys the purpose of the guide. It happens also on stock based custom roms and that probably means it is ROM related. The same happens on stock and ultra kernels, the weird part is that it somehow worked normally on stock 6.0 and squid kernel even though not from the day one. Any ideas how to make hispeed_freq to stick to 533333MHz?
http://imgur.com/SS1ZWaf
EDIT: title should be CPU governor tunables on stock and custom kernels problem. My keyboard is dying.
Click to expand...
Click to collapse
It does stick if you use profiles in k.a.,but every time you launch an app its reverting for about 2 seconds showing the 1459Mhz and reverts back to normal when the app is finished loading. It works but still not perfect and im googling for days to solve this issue.It has something to do with a stock qualcom script that tries to overwrite the settings when you launch an app. I found the files to edit the go_hispeed_freq and i also have read and write acces but every time I try to change it just reverts back. Very frustrating.
Its located in: /sys/devices/system/cpu
Strange thing is even when you have set the correct hispeed freq and it works fine, it doesnt change it in the sys/devices/system/cpu directory when using a file browser.

Hello Viper if you are still tweaking with this governor I think I found the cause. Takes a little risk to fixnbecause you have to use stock android interactive and on demand standard settings instead of Motorola's settings. Found a few posts people with similar issues and they deleted (I renamed it for backup) the "init.qcom.post.boot.sh" file. Seems like this file gets messed up when you flash a custom kernel. You can check it with a text editor and see its constantly showing very strange freqs and switching between ondemand and interactive constantly (weird). After I renamed it to .bak everything sticks after applying the profile and CPU monitor apps also seems to react different with lot less ramping up the cores and the 1.4 freq doesn't show up anymore like before.

Sickaxis79 said:
Hello Viper if you are still tweaking with this governor I think I found the cause. Takes a little risk to fixnbecause you have to use stock android interactive and on demand standard settings instead of Motorola's settings. Found a few posts people with similar issues and they deleted (I renamed it for backup) the "init.qcom.post.boot.sh" file. Seems like this file gets messed up when you flash a custom kernel. You can check it with a text editor and see its constantly showing very strange freqs and switching between ondemand and interactive constantly (weird). After I renamed it to .bak everything sticks after applying the profile and CPU monitor apps also seems to react different with lot less ramping up the cores and the 1.4 freq doesn't show up anymore like before.
Click to expand...
Click to collapse
Hi Sickaxis79 and sorry for the late reply, I've been working a lot lately. I gave up on interactive settings b/c my battery life was awful on interactive gov . but now that you mentioned this i'll give it another go this weekend and will let you know what are the results.
Can you just tell me where can I locate init.qcom.post.boot.sh file?
Thanks for showing interest to help me out, I appreciate it bro.

I was wrong,lol. Don't rename it or your battery start to drain when idle.
It contains all your governor settings and how your big.LITTLE cores work together (HMP Scheduler).
The good part is that you can edit this file and search for your model.nr "msm8939" with a unix text editor and enter all governor settings directly into this post_boot.sh file (i use quickedit app or notepad++ for pc) and you don't need a kernel manager anymore. The hispeed_freq will also stick and only for a few seconds you can see it when you switch apps, but it doesn't revert back to 1,4MHz permanently like before.
The file is located in /system/etc/init.qcom.post_boot.sh
Peace

[Kernel][3.4.113] Chrono Kernel R5.10

Custom kernel for Samsung Galaxy S Advance
Code:
/*
* Your (probably expired) warranty is now void.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this kernel
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
*/
Features:
Universal kernel for JB, KK, LP and MM-based ROMs
CPU, GPU and DDR OC support
more governors and I/O schedulers
Lite kernel - some kernel features moved as modules
F2FS support
ABB-charger tweaks
many others features and tweaks...
Credits:
@dh.harald and @hafidzduddin for contribution on U8500 platform sources
@ Team Canjica for a base for this kernel
@ Nova Fusion for F2FS implementation
@zwliew for contribution on TC kernel
@cocafe for LiveOPP, GPU OC, abbamp and abb-charger tweaks and many cool patches which I've used from his kernel
@faux123 for dynamic Fsync implementation
@Christopher83 for dynamic management of dirty page writebacks implementation
@KINGbabasula for contribution on TC kernel sources
@boype for SIOPlus tweaks and OndemandPlus governor
@Adi_Pat for abbamp, kernel tweaks
@PolishVodka for initramfs scripts for 4.2.x and 5.0.x
@Rox for help in fixing initramfs scripts for 4.1.2
@ace2nutzer for optimization CPU OC and for whatever scripts which I have used in my kernel
@Meticulus for BLN, Sweep2wake and Doubletap2wake
@mkaluza for huge LiveOPP/Mali improvements and Dynamic governor
@yanpol199 for help with F2FS support in TWRP
@ all users who tests this kernel and directs the development along the right path
@ all those users, who I forgot to mention (PM me if so)
Team Win for TWRP recovery
Samsung for opening kernel source
Linus Torvalds for Linux sources
Special Thanks:
@isaak, @enkflr, @Pdevo, @prometej-zg for donating this phone!
[*]@S.AMU for providing FTP-Server
Source Code:
LK 3.10.y based releases
r5.7.x (LK 3.4.y based releases)
Installation:
Flash temporary kernel (if coming from other recoveries than TWRP 3.1.1)
Reboot recovery
Flash kernel zip
Compatibility:
I only add those ROMs that are confirmed to work by me or someone else:
Stock 4.1.2 ROM
LineageOS 11
CyanogenMod 13
Notice: this kernel is not compatible with NovathorSettings app, be sure to remove it before installing a kernel!
Download:
FTP
XDA:DevDB Information
Chrono Kernel, Kernel for the Samsung Galaxy S Advance I9070
Contributors
ChronoMonochrome, cocafe, faux123, zwliew, mkaluza, Meticulus, KINGbabasula, ace2nutzer, TeamCanjica
Source Code: https://github.com/ChronoMonochrome/Chrono_Kernel-1/commits/master
Kernel Special Features:
Version Information
Status: Stable
Current Stable Version: R5.7.1
Stable Release Date: 1974-11-11
Beta Release Date: 1974-11-11
Created 2018-03-09
Last Updated 2018-04-16

Changelogs and features
Changelog
R5.9.1
Resolved (hopefully) deepsleep issues *
Fixed touchkey not working issue **
* tested in about 24 hours so far with ~6 hours of deep sleep on UltimateROM 6.0.1 without any issues with wakelocks.
** It seems that in r5.9 was introduced a bug - touch keys weren't working (at least, on 6.0.1) after device wake up.
R5.9
Bring up all the latest CK code from Codina kernel
Fix a severe performance issue on r5.8.2 build
BLN is finally FIXED! *
* Apparently, issues with BLN were related to Janice touchkey driver that was putting the device to sleep (when the display is off) regardless of a BLN wakelock usage. Reverting this behavior seemed to enable BLN to work.
R5.8.2
In-kernel vibrator fix for Android 6.0+
R5.8.1
PowerHAL fixes for 4.4.4
Experimental fix for CPU governor issue on 4.4.4
LCDCLK: revert to TeamCanjica kernel implementation
R5.8
Memory management hugely improved (finally LMK works properly)
Fixed powersave interface on JB 4.1.2 stock
Experimental fixes to PowerHAL on 4.4.4
LiveOPP: merged changes from refresh kernel (removed some CPU freq steps)
Dynamic: adjust tunables (same like in refresh kernel)
Possible vibrator fix on 6.0+ (not tested)
(old changelog)
R5.7.1
Initial build for janice (kernel sources based on LineageOS 15.1 kernel for Codina)
Fixed bluetooth issue on 4.1.2
Squash-reverted GPU-related code logic from CPU governor Dynamic
J4FS module code cleanup
Reverted forcing minimum CPU freq to 800 MHz
Enabled CONFIG_CPUSETS (required by Android 6.0.x+ ROMs to function properly)
Kernel Tweaks:
(GPU/CPU undervolting and related tweaks)
Undervolting the CPU/GPU will bring battery savings but possible instability.
1) to undervolt CPU use ChronoKernel app or via init.d scripts:
Code:
echo *cpufreq* varm=xx > /sys/kernel/liveopp/arm_summary
for example, following sets voltage varm=0x10 for 200 MHz:
Code:
echo 200000 varm=0x10 > /sys/kernel/liveopp/arm_summary
or
Code:
echo 200000 varm-=10 > /sys/kernel/liveopp/arm_summary
(default varm voltage for 200 MHz is 0x1a but, code above sets 0x1a - 0xa(10) = 0x10 )
2) to undervolt GPU use init.d script:
Code:
echo x vape=yy > /sys/kernel/mali/mali_dvfs_config
Example:
Code:
echo 2 vape=0x1c > /sys/kernel/mali/mali_dvfs_config
"2" stands for DVFS idx (look at mali_boost_high/mali_boost_low).
To prevent overriding of such settings by ChronoKernel app, add line to your init.d script after GPU undervolting
Code:
chmod 444 /sys/kernel/mali/mali_dvfs_config
Don't change voltage of both GPU/CPU at the same time - otherwise if you'll get reboot if won't know what it caused. The same is for different frequencies - if you'll change voltage of too many steps you won't know which frequency caused reboot. It's not easy process, though, following method simplifies it: https://github.com/mkaluza/i9070_kernel_CoCore-E/wiki/Undervolting-janice .
3) Custom LiveOPP table.
By default some LiveOPP steps such as 100, 200, 500 ... MHz aren't used. You can re-enable those by following way:
Code:
echo 200000 enable=1 > /sys/kernel/liveopp/arm_summary
Or use CK app instead. Don't enable it unless it uses the same voltage as 400 MHz. The same is for the rest frequencies - until some of them uses same voltage, no point to enable steps with lower freq. I've added 100 MHz just to further make some tests with it once again. It can't use lower varm than 200 MHz - that's why it's disabled by default. Furthermore, not all phones well keep undervoltage, that's why 100-400 MHz steps uses same stock voltage varm=0x1a.
UPD. thanks to @borkins for this nice editor LiveOPP ARM steps: http://forum.xda-developers.com/showpost.php?p=60311291&postcount=2921
(CPU freq management tweaks)
CPU freq. limiter for screen OFF, adjust it via:
Code:
SYSFS=/sys/kernel/cpufreq/cpufreq_limits_on_suspend
echo min=100000 > $SYSFS
echo max=400000 > $SYSFS
echo on > $SYSFS
Too low frequency may cause freezes after wakeup and sound scrathes. If you use Dynamic govermor, it make no sense to use cpufreq limiter, because Dynamic already takes care about CPUfreq usage optimization. For more, read wiki.
Input boost
This feature has been originally written by zwliew.
Not all governors support input boost. Supported governors: ondemand, interactive, conservative, ZenX, lionheart and some others. Dynamic governor has its own boost interface.
Default boost frequency is 400 MHz.
Code:
echo 450000 > /sys/kernel/cpufreq/input_boost_freq # echo '0' to disable
echo 35 /sys/kernel/cpufreq/input_boost_ms
(BackLight Notification)
To configure time intervals of BLN blinking type(bln_ondelay stands for time of blink and bln_offdelay - delay between two blinks):
Code:
echo bln_ondelay=500 > /sys/kernel/bln/blink_mode
echo bln_offdelay=6000 > /sys/kernel/bln/blink_mode
Make sure BLN enabled:
Code:
echo 1 > /sys/class/misc/backlightnotification/enabled
# to enable bln_wakelock.
echo on > /sys/kernel/bln/bln_wakelock
Use /sys/devices/virtual/misc/backlightnotification/blink_mode to changes modes.
Blink modes:
0 = no blinking
1 = blink backlight only
2 = blink backlight + rear cam flash
3 = blink rear cam flash only
(Module autoload)
Now there is a simple way to load modules at boot. Just move needed modules to /system/lib/modules/autoload and reboot device(or execute /etc/init.d/00autoload)
(DDR overclock)
This feature has been developed by me and allows you to improve DDR and GPU performance. Please note, that DDR OC might work unstable and cause filesystem corruption. Though, DDR clock of 975 MHz has been highly tested and should work fairly stable on most devices.
Overclocking DDR over 975 MHz is highly NOT recommended, especially in case if you not sure that you can deal with possible consequences.
How to OC DDR:
1) by using
this script .
2) by using Terminal Emulator(in example below 975 MHz):
Code:
echo 0x5017f > /sys/kernel/liveopp/pllddr_oc_on_suspend
This setting will be applied right after disabling screen.
(Minimum APE/DDR OPP on screen on)
This feature has been developed by me and allows to set minimum APE/DDR OPP states which are used when screen is ON. APE controls many systems such as an image, video, audio system etc. DDR OPP determines performance of DDR. Default values are APE50 and DDR50. Lower states(APE25/DDR25) reduces power consumption, but may cause graphical glitches like screen blinking or filling it by vertical grey lines. If you don't have mentioned effects, it's recommended to use APE25/DDR25:
Code:
echo ddropp=25 > /sys/devices/pri_lcd_ws2401.0/mcde_screenon_opp
echo apeopp=25 > /sys/devices/pri_lcd_ws2401.0/mcde_screenon_opp
* if you don't have folder /sys/devices/pri_lcd_ws2401.0, use /sys/devices/pri_lcd_s6d27a1 instead.
(Screen refresh rate)
This feature has been developed by cocafe and modified by me. Lower lcdclk frequency cause less power usage, but too low values makes system unusable.
Following command allows to change screen refresh rate:
Code:
echo x > /sys/kernel/mcde/lcdclk
use
Code:
cat /sys/kernel/mcde/lcdclk
to see supported lcdclk modes. Default mode is 60 Hz which is recommended in most typical cases. If you've screen tearings, blinking etc. change resresh rate mode to "60+ Hz":
Code:
echo 0 > /sys/kernel/mcde/lcdclk
(ABB charger tweaks)
added tweakable interfaces for termination current. To adjust it type(just an example):
Code:
echo 90 > /sys/kernel/abb-chargalg/termination_curr_1st
echo 70 > /sys/kernel/abb-chargalg/termination_curr_2nd
curr_2nd should be less or same as curr_1st. Lower values prolongs battery lifetime, but also slows battery charging.
Default values are curr_1st == curr_2nd == 150 mA. Please note, too low values maybe aren't usable.
(Dynamic FSync)
This feature has been developed by Faux123 and allows to dynamically manage the synchronous writes performed on file system (FSync).
It uses asynchronous writes when the screen is on, instead of synchronous writes, to have better performance and a slightly lower battery drain, while when the screen is off the synchronous writes are re-enabled to flush all the outstanding writes and prevent possible data loss.
How to enable/disable the Dynamic FSync (default enabled):
1) By downloading and using Trickster MOD
2) By directly editing the file /sys/kernel/dyn_fsync/Dyn_fsync_active and setting 1 to enable the dynamic fsync, 0 to disable it (note that set value will be lost after a reboot/shutdown)
3) By using Terminal Emulator (note that set value will be lost after a reboot/shutdown)
- Open Terminal Emulator
- Run this command to disable the dynamic fsync feature
Code:
su
echo 0 > /sys/kernel/dyn_fsync/Dyn_fsync_active
- Or run this command to re-enable the dynamic fsync feature
Code:
su
echo 1 > /sys/kernel/dyn_fsync/Dyn_fsync_active
Click to expand...
Click to collapse
(Software CRCs)
Disabling software CRCs gives you a slight bump(10-30% is what they say) of MMC performance, at the cost of a possibility of your Ace 2 freezing randomly.
Code:
echo 0 > /sys/module/mmc_core/parameters/use_spi_crc
Click to expand...
Click to collapse
(Dynamic dirty page writebacks)
This feature has been developed by Christopher83 and allows to dynamically manage the dirty page writebacks with two different intervals, one when the screen is on and another when the screen is off.
It is based on a commit of Francisco Franco, but instead of using hard coded values and of disabling at all the dirty page writebacks while the screen is on (possibility of data loss).
By using a higher interval we have better performance and less battery consumption, with a very low risk of data loss.
How to customize the dynamic dirty page writebacks feature (default disabled):
Three new procfs parameters are exposed inside /proc/sys/vm path:
- dynamic_dirty_writeback is the activation status of this feature, set 1 to enable it, set 0 to disable it and use the standard behaviour
- dirty_writeback_active_centisecs is the interval for the dirty page writebacks when the system is active (screen on), the default value is 1500 centisecs (15 seconds)
- dirty_writeback_suspend_centisecs is the interval for the dirty page writebacks when the system is suspended (screen off), the default value is 500 centisecs (5 seconds)
1) By directly editing one of the file written above inside /proc/sys/vm and setting the preferred value (note that set value will be lost after a reboot/shutdown)
2) By using Terminal Emulator (note that set value will be lost after a reboot/shutdown)
- Open Terminal Emulator
- Run this command to disable the dynamic dirty page writebacks feature
Code:
echo 0 > /proc/sys/vm/dynamic_dirty_writeback
- Or run this command to re-enable the dynamic dirty page writebacks feature
Code:
echo 1 > /proc/sys/vm/dynamic_dirty_writeback
- Run this command to set customize the two intervals (30 seconds while the screen is on, 10 seconds when the screen is off)
Code:
echo "3000" > /proc/sys/vm/dirty_writeback_active_centisecs
echo "1000" > /proc/sys/vm/dirty_writeback_suspend_centisecs
(Tweak app)
ChronoKernel settings
Thanks mars_army for this app!
Bug reports:
after experiencing a random reboot, type in terminal:
Code:
su
cat /proc/last_kmsg > /storage/sdcard0/last_kmsg.txt
report it in the thread and attach the last_kmsg.txt

Misc
Storages switch
By default, this kernel comes with internal and external storages switched. You can revert this behavior, by changing the line
Code:
use_swap=1
to
Code:
use_swap=0
in file /ramdisk/fstab_specs.txt and flashing the kernel package. This setting will remain until you format /ramdisk partition.

@ChronoMonochrome
I tested "chrono_kernel_r5.7.1-test-40-g169a68f4f29d-janice.zip" on Lineage OS 11.
Result: I have the same hiccups in the youtube video like before.
I think that you can revert the LCDCLK frequency to the default 60 Hz value, because I didn't notice any significant difference.
And I had an isolated crash while I was navigating in settings.
My usual running apps & services are: Should I answer?, Nova Launcher, Tesla Unread, Google Play Services 11.9.75, Ginger Keyboard, Skype 7.46.0.596 (old version from apkmirror), Quickpic, Terminal Emulator, CCleaner, Google Play Store 9.0.15, Tubemate 3.0.11, My Vodafone, Naked Browser, Titanium Backup, Fx File Explorer, Gmail, Google News & Weather, MX Player.
I hope that these logs can help you.

isaak said:
@ChronoMonochrome
I tested "chrono_kernel_r5.7.1-test-40-g169a68f4f29d-janice.zip".
Result: I have the same hiccups in the youtube video like before.
I think that you can revert the LCDCLK frequency to the default 60 Hz value, because I didn't notice any significant difference.
And I had an isolated crash while I was navigating in settings.
My usual running apps & services are: Should I answer?, Nova Launcher, Tesla Unread, Google Play Services 11.9.75, Ginger Keyboard, Skype 7.46.0.596 (old version from apkmirror), Quickpic, Terminal Emulator, CCleaner, Google Play Store 9.0.15, Tubemate 3.0.11, My Vodafone.
I hope that these logs can help you.
Click to expand...
Click to collapse
Thanks for the report! Unfortunately, the last_kmsg log appears to be taken from MaxiCM kernel, so the crash isn't captured here. In the meantime I'll install some of those apps to test how it goes under increased memory pressure. Was /proc/meminfo log taken before or after reboot? It would be useful to check this sysfs interface when the phone is encountering laggs (if it does), but after reboot this info won't help. About lowmemorykiller changes: were apps running faster / slower? So far Youtube playback is the only issue or phone laggs too?

ChronoMonochrome said:
Thanks for the report! Unfortunately, the last_kmsg log appears to be taken from MaxiCM kernel, so the crash isn't captured here. In the meantime I'll install some of those apps to test how it goes under increased memory pressure. Was /proc/meminfo log taken before or after reboot? It would be useful to check this sysfs interface when the phone is encountering laggs (if it does), but after reboot this info won't help. About lowmemorykiller changes: were apps running faster / slower? So far Youtube playback is the only issue or phone laggs too?
Click to expand...
Click to collapse
/proc/meminfo log was taken before the reboot. Youtube playback is not the only issue. I can just say that the best way to reproduce a crash or a slowdown is switching from an app to another as quick as possible and/or try a cleaning with CCleaner. Ah, in that list I forgot some apps, so I've updated my previous post.

So far I've tested as much as possible on stock 4.1.2 rom and everything is working fine.
-Bluetooth is definitely fixed, working like a charm.
-CRC, FSYNC and other tweaks give me no issue at all and work good.
-Tested a bit of undervolting, firstly cpu, then gpu, and DDR OC, and here too, no problems.
-Really great the supension min and max cpufreq, tested it with some init.d scripts.
Overall stability and responsiveness of the system is impressive, really positive, you really made a big surprise
These instead are the few things I noticed not working, I think the first two are really not a major problem at all and maybe I am messing with something:
1. I have noticed that trying to set governor by init.d script doesn't seem to take effect and at boot completed I find performance setted as governor:
busybox echo dynamic > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor;
Click to expand...
Click to collapse
Running then the script manually set dynamic as governor correctly.
(SOLVED WITH A BUSYBOX CHMOD COMMAND BEFORE EVERY PARAMETER SET)
2. I tryed using exfat support, loaded fuse.ko and exfat.ko modules on boot, then used the same binary from cocafe twrp kernel I was using fine (and here I think there is the issue) with this command:
exfat-fuse /dev/block/mmcblk1p1 /storage/extSdCard;
Click to expand...
Click to collapse
Sdcard isn't recognized and android is asking to format it as usual.
3. I guess should be the number one: Recovery doesn't seem to work, tryed many times, also removing battery first, but I can't enter in recovery. Next time I flash kernel I will do it manually from terminal, or Universal Kernel Flash app
EDIT1:
I found that the path where lcd parameters are located would be:
/sys/kernel/s6e63m0/panel/lcd_clk
Click to expand...
Click to collapse
instead of:
/sys/kernel/mcde/lcdclk
Click to expand...
Click to collapse
EDIT2:
Seems like deepsleep is broken, because in my situation phone doesn't enter in deepsleep mode and having a look at /d/supsend_stats and d/suspend directory confirm my issue.
I found at first strange the absence of /d/cpuidle directory and so the deepest_state configuration file, like something is missing here.
EDIT3:
I think I found another last issue, BLN is not working, but I think could be again something to do with files and folder structure, for example I can't find:
/sys/class/misc/backlightnotification/enabled
Click to expand...
Click to collapse
Again, this is still something not so important tough
EDIT4:
I was experiencing before issues with phone calls, making phone app freezing and signal loss, going to "no service" mode. Had to flash backup kernel for now, tomorrow as I get some time again I will provide logs

Pdevo said:
So far I've tested as much as possible on stock 4.1.2 rom and everything is working fine.
-Bluetooth is definitely fixed, working like a charm.
-CRC, FSYNC and other tweaks give me no issue at all and work good.
-Tested a bit of undervolting, firstly cpu, then gpu, and DDR OC, and here too, no problems.
-Really great the supension min and max cpufreq, tested it with some init.d scripts.
Overall stability and responsiveness of the system is impressive, really positive, you really made a big surprise
Click to expand...
Click to collapse
Thanks for a review!
2. I tryed using exfat support, loaded fuse.ko and exfat.ko modules on boot, then used the same binary from cocafe twrp kernel I was using fine (and here I think there is the issue) with this command:
Sdcard isn't recognized and android is asking to format it as usual.
Click to expand...
Click to collapse
Honestly I didn't test exfat for a long time. These issues might come due to the filesystem driver updates. Anyway I need to test things myself before I'll have clues on how to fix it.
3. I guess should be the number one: Recovery doesn't seem to work, tryed many times, also removing battery first, but I can't enter in recovery. Next time I flash kernel I will do it manually from terminal, or Universal Kernel Flash app
Click to expand...
Click to collapse
Are you sure you have followed the installation guide to flash the kernel? Especially, using TWRP is required to flash a kernel (other recoveries aren't tested and can be a cause for a bugs) I was returning to a stock for a short time to test if bluetooth works and recovery was working for me when I was returning to UltimateROM 6.0.1 afterwards.
Don't use manual flashing or UKF app to flash the kernel! The installation method is quite complicated (compared to installation of other kernels), so a full and proper installation is only possible if you flash it from recovery.
EDIT1:
I found that the path where lcd parameters are located would be:
instead of:
Click to expand...
Click to collapse
I have moved the interface to match the implementation of LCDCLK management on codina.
EDIT2:
Seems like deepsleep is broken, because in my situation phone doesn't enter in deepsleep mode and having a look at /d/supsend_stats and d/suspend directory confirm my issue.
I found at first strange the absence of /d/cpuidle directory and so the deepest_state configuration file, like something is missing here.
Click to expand...
Click to collapse
This is entirely possible due to deepsleep driver changes in a kernel. I never tested if it works on stock, I guess I'll have to return to stock once again.
EDIT3:
I think I found another last issue, BLN is not working, but I think could be again something to do with files and folder structure, for example I can't find:
Again, this is still something not so important tough
Click to expand...
Click to collapse
I was thinking BLN isn't working on this phone at all, so I disabled the kernel support. Is the stock ROM only where BLN works?

Yes sir, I flashed your kernel exactly from twrp, coming from cocore refresh24, I referred to UKF or terminal emulator to say I would use that method now that I can't enter recovery mode, but I never use these ways at all, always from recovery, because I know that kernel come with scripts and other files that without recovery wouldn't be installed
Tomorrow I will do further testing

ChronoMonochrome said:
I was thinking BLN isn't working on this phone at all, so I disabled the kernel support. Is the stock ROM only where BLN works?
Click to expand...
Click to collapse
As far as I know no dev on Janice introduced BLN, but I don't see any reason why it shouldn't be technically possible if it works on Ace II.
Please don't give up on this unless you're sure at 100%.
@cocafe had it on his todo list, but at the end he didn't implement it for unknown reasons. I asked to him but he never explained it.

ChronoMonochrome said:
I was thinking BLN isn't working on this phone at all, so I disabled the kernel support. Is the stock ROM only where BLN works?
Click to expand...
Click to collapse
Until now, BLN never been working or supported on custom and stock roms, as said by @isaak, the reason behing that I think is properly known by developers such as cocafe.
Yesterday I made a little try using the commands you point in the thread, a little go, but in fact is not working. Would be a cool feature, but nothing so important at all for me, at least for now
UPDATE:
I flashed again the kernel, starting from freshly downloaded zip, and I got an infinite bootloop trying to get to recovery, the only way to go back working was flashing stock rom with odin.
I can now safely say there is an issue with recovery using the stock rom.
UPDATE 19:30
I took two logs, one for incoming call and one for outgoing call, reproducing the issue I was referring in previous post.
In the first case, incoming call, notification appear but scrolling to accept call make phone unusable and I could just shutdown it to solve the situation.
In the second case, outgoing call, after I start the call the phone app isn't responding, I see the notification widget but tapping on every possible button, to terminate call or enter in dialog, doesn't work and phone is very unstable until a sort of a timeout is running out and call stop itself.

Hi @ everyone!
Because of th numerous issues found with the current release, I'm starting to work on a fresh kernel sources (3.0.101), almost from scratch. My primary focus for now will be a multitasking, that is the main issue with the current release. Because of yet unknown root cause of the issue it could take a while to reveal it, but I hope to release a new build these days (and after playing with some kernel configuration find out more appropriate one for a multitasking). Stay tuned!

For sure we stay tuned!, thank you so much for the efforts and take all the time you need Chrono

isaak said:
My usual running apps & services are: Should I answer?, Nova Launcher, Tesla Unread, Google Play Services 11.9.75, Ginger Keyboard, Skype 7.46.0.596 (old version from apkmirror), Quickpic, Terminal Emulator, CCleaner, Google Play Store 9.0.15, Tubemate 3.0.11, My Vodafone, Naked Browser, Titanium Backup, Fx File Explorer, Gmail, Google News & Weather, MX Player.
I hope that these logs can help you.
Click to expand...
Click to collapse
I have set up all these apps about 10-12 days ago. I should say, removing CCleaner seemed to help a lot to increase the phone performance. It's doing a lot of background CPU and I/O work, making the phone almost unusable on r5.7.1 and severely affects performance on r4.1 / r4.6.

ChronoMonochrome said:
I have set up all these apps about 10-12 days ago. I should say, removing CCleaner seemed to help a lot to increase the phone performance. It's doing a lot of background CPU and I/O work, making the phone almost unusable on r5.7.1 and severely affects performance on r4.1 / r4.6.
Click to expand...
Click to collapse
The new CCleaner version is on the heavy side, so I had to freeze some background services with My Android Tools app. Anyway I've just uninstalled it definitively.

New build r5.8 is up!
R5.8
Memory management hugely improved (finally LMK works properly)
Fixed powersave interface on JB 4.1.2 stock
Experimental fixes to PowerHAL on 4.4.4
LiveOPP: merged changes from refresh kernel (removed some CPU freq steps)
Dynamic: adjust tunables (same like in refresh kernel)
Possible vibrator fix on 6.0+ (not tested)

ChronoMonochrome said:
R5.8
Memory management hugely improved (finally LMK works properly)
Fixed powersave interface on JB 4.1.2 stock
Experimental fixes to PowerHAL on 4.4.4
LiveOPP: merged changes from refresh kernel (removed some CPU freq steps)
Dynamic: adjust tunables (same like in refresh kernel)
Possible vibrator fix on 6.0+ (not tested)
Click to expand...
Click to collapse
I tried 5.8.5 and I have still issues with LineageOS 11:
1) I've got a screen flicker issue while I was browsing in Naked Browser with the new LCDCLK frequency.
Tried to set echo 1 > /sys/kernel/mcde/lcdclk, but I've noticed that this value is not kept after a reboot.
Very annoying, because I can't restore 60 Hz permanently.
2) There are still issues about some values not kept in the performance UI of Lineage Os.
For example:
- Try to set Zenx as governor, min. 200 max 1000, Noops scheduler. Reboot. Scheduler will be resetted to Deadline.
- There is still a bug with max clock value of Dynamic governor (I can reproduce it with ZenX governor too). I set it to 800 MHz, I go back to the settings screen, then I return to the Performance -> Processor section to check if the 800 MHz value is maintained. But the UI automatically restored the max clock to 1000 MHz without my consent.
For your information, these issues occur only randomly and with particular combinations. So, if you can't reproduce them, the best way is to set these, one at a time:
1) Zenx as governor, min. 200 max 800, Noops scheduler. Reboot.
2) Zenx as governor, min. 200 max 800, Fiops scheduler. Reboot.
2) Zenx as governor, min. 200 max 800, Sioplus scheduler. Reboot.
After the first, the second or the third reboot, some of these values you've set will change spontaneously on their own.
"Set on boot" options are correctly set for both Processor and I/O Scheduler.
And I keep "Enable per-app profiles" option turned off.
3) On the Performance UI, performance profile results automatically set on Balanced after any reboot. But if you cannot fix it, I can live with that, don't worry. It doesn't keep "Power save" or "Performance" profile between reboots.
PS: I would appreciate if you could update the installation steps in this thread with the same steps of the refresh topic:
Flash temporary kernel (if coming from other recoveries than TWRP 3.1.1)
Reboot recovery
Flash kernel zip

isaak said:
I tried 5.8.5 and I have still issues with LineageOS 11:
1) I've got a screen flicker issue while I was browsing in Naked Browser with the new LCDCLK frequency.
Tried to set echo 1 > /sys/kernel/mcde/lcdclk, but I've noticed that this value is not kept after a reboot.
Very annoying, because I can't restore 60 Hz permanently.
Click to expand...
Click to collapse
Sorry, I thought I've reverted this change. Can you confirm that setting old LCDCLK freq fixes issue? As a temporary solution you can use init.d script to set the appropriate LCDCLK freq index.
2) There are still issues about some values not kept in the performance UI of Lineage Os.
For example:
- Try to set Zenx as governor, min. 200 max 1000, Noops scheduler. Reboot. Scheduler will be resetted to Deadline
Click to expand...
Click to collapse
Can confirm now. I have a guess for that, for now the solution as follows:
remove /ramdisk/modules/autoload/sioplus-iosched.ko, reboot. I have to test this a bit more time to be sure 100%, but so far I couldn't reproduce an issue after removing this module (no other CPUfreq governor or I/O scheduler must be loaded as well).
- There is still a bug with max clock value of Dynamic governor (I can reproduce it with ZenX governor too). I set it to 800 MHz, I go back to the settings screen, then I return to the Performance -> Processor section to check if the 800 MHz value is maintained. But the UI automatically restored the max clock to 1000 MHz without my consent.
Click to expand...
Click to collapse
It's not a bug, but rather intended behavior - due to PowerHAL changes implemented, CPUfreq can only be changed via script (see /ramdisk/perf.sh). I've previously asked if anyone would prefer to adjust CPUfreq usual way, In this case I can just remove the corresponding lines from the PowerHal script. This will make PowerHAL settings a bit more useless, but will gave easier control over CPUfreq.
3) On the Performance UI, performance profile results automatically set on Balanced after any reboot. But if you cannot fix it, I can live with that, don't worry. It doesn't keep "Power save" or "Performance" profile between reboots.
Click to expand...
Click to collapse
The script actually works, though you're right, it works buggy and everytime shows the default profile (you can set, e.g. Powersave profile and check min/max CPU freq, to check if it actually works).
PS: I would appreciate if you could update the installation steps in this thread with the same steps of the refresh topic:
Flash temporary kernel (if coming from other recoveries than TWRP 3.1.1)
Reboot recovery
Flash kernel zip
Click to expand...
Click to collapse
Done!

isaak said:
I've got a screen flicker issue while I was browsing in Naked Browser with the new LCDCLK frequency.
Tried to set echo 1 > /sys/kernel/mcde/lcdclk, but I've noticed that this value is not kept after a reboot.
Very annoying, because I can't restore 60 Hz permanently.
ChronoMonochrome said:
Sorry, I thought I've reverted this change. Can you confirm that setting old LCDCLK freq fixes issue? As a temporary solution you can use init.d script to set the appropriate LCDCLK freq index.
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Yes, I can confirm that setting old LCDCLK freq fixed the flicker issue for my screen. I think it would be better to set it as default in the next release.
isaak said:
There are still issues about some values not kept in the performance UI of Lineage Os.
For example:
- Try to set Zenx as governor, min. 200 max 1000, Noops scheduler. Reboot. Scheduler will be resetted to Deadline
etc etc....
ChronoMonochrome said:
Can confirm now. I have a guess for that, for now the solution as follows:
remove /ramdisk/modules/autoload/sioplus-iosched.ko, reboot. I have to test this a bit more time to be sure 100%, but so far I couldn't reproduce an issue after removing this module (no other CPUfreq governor or I/O scheduler must be loaded as well).
Click to expand...
Click to collapse
Click to expand...
Click to collapse
I tried your steps, unfortunately they didn't work for me.
ChronoMonochrome said:
It's not a bug, but rather intended behavior - due to PowerHAL changes implemented, CPUfreq can only be changed via script (see /ramdisk/perf.sh). I've previously asked if anyone would prefer to adjust CPUfreq usual way, In this case I can just remove the corresponding lines from the PowerHal script. This will make PowerHAL settings a bit more useless, but will gave easier control over CPUfreq.
Click to expand...
Click to collapse
Personally I would prefer more control over CPUfreq. Could you list the main advantages to limit CPUfreq changes only via script? Is it a sort of auto-optimization? This point is not clear to me. If you think that any change to this mechanism would affect negatively the battery life, then don't change anything.
isaak said:
On the Performance UI, performance profile results automatically set on Balanced after any reboot. But if you cannot fix it, I can live with that, don't worry. It doesn't keep "Power save" or "Performance" profile between reboots.
ChronoMonochrome said:
The script actually works, though you're right, it works buggy and everytime shows the default profile (you can set, e.g. Powersave profile and check min/max CPU freq, to check if it actually works).
Click to expand...
Click to collapse
Click to expand...
Click to collapse
I tried Powersave and Performance profiles, in both cases the maximum freq varies between 400 MHz and 1000 MHz, rarely reaching 800 MHz. Minimum freq is always 200 MHz and it doesn't change visually like the maximum freq. Balanced profile is always shown visually after a reboot.

isaak said:
Personally I would prefer more control over CPUfreq. Could you list the main advantages to limit CPUfreq changes only via script? Is it a sort of auto-optimization? This point is not clear to me. If you think that any change to this mechanism would affect negatively the battery life, then don't change anything.
Click to expand...
Click to collapse
Because of some CPUfreq scaling tunables were changed (in the case of Dynamic governor), it makes sense to implement a PowerHAL profiles, which would limit / restore the max CPUfreq. But I think I've found a solution - I will make it possible to change CPUfreq for a Balanced profile.
I tried Powersave and Performance profiles, in both cases the maximum freq varies between 400 MHz and 1000 MHz, rarely reaching 800 MHz. Minimum freq is always 200 MHz and it doesn't change visually like the maximum freq. Balanced profile is always shown visually after a reboot.
Click to expand...
Click to collapse
Ok, I found some logical errors in the script, should be fixed in upcoming release.

[Kernel][3.0.101] Chrono Kernel Refresh R4.6.2

Custom kernel for Samsung Galaxy S Advance
Code:
/*
* Your (probably expired) warranty is now void.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this kernel
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
*/
Hi there!
Because of numerous issues found in 3.4.113 kernel, I'm temporarily moving to development on 3.0.101 base.
What is difference between chrono kernel (CK) and CK refresh build? CK was mostly tested on MM-based ROMs, but appeared not to work stably on Android 4.4.x. Aim of this build is to properly enable support for older ROMs (like kitkat), and when done, merge these changes to 3.4.113 kernel.
This build is based upon chrono kernel r4.1 build, so to avoid versions confusion, I'm creating a separate topic.
Features:
CPU, GPU and DDR OC support
more governors and I/O schedulers
Lite kernel - some kernel features moved as modules
F2FS support
ABB-charger tweaks
many others features and tweaks...
Credits:
@dh.harald and @hafidzduddin for contribution on U8500 platform sources
@ Team Canjica for a base for this kernel
@ Nova Fusion for F2FS implementation
@zwliew for contribution on TC kernel
@cocafe for LiveOPP, GPU OC, abbamp and abb-charger tweaks and many cool patches which I've used from his kernel
@faux123 for dynamic Fsync implementation
@Christopher83 for dynamic management of dirty page writebacks implementation
@KINGbabasula for contribution on TC kernel sources
@boype for SIOPlus tweaks and OndemandPlus governor
@Adi_Pat for abbamp, kernel tweaks
@PolishVodka for initramfs scripts for 4.2.x and 5.0.x
@Rox for help in fixing initramfs scripts for 4.1.2
@ace2nutzer for optimization CPU OC and for whatever scripts which I have used in my kernel
@Meticulus for BLN, Sweep2wake and Doubletap2wake
@mkaluza for huge LiveOPP/Mali improvements and Dynamic governor
@yanpol199 for help with F2FS support in TWRP
@ all users who tests this kernel and directs the development along the right path
@ all those users, who I forgot to mention (PM me if so)
Team Win for TWRP recovery
Samsung for opening kernel source
Linus Torvalds for Linux sources
Special Thanks:
@isaak, @enkflr, @Pdevo, @prometej-zg for donating this phone!
[*]@S.AMU for providing FTP-Server
Source Code:
LK 3.0.y based releases
Installation:
Flash temporary kernel (if coming from other recoveries than TWRP 3.1.1)
Reboot recovery
Flash kernel zip
Notice: this kernel is not compatible with NovathorSettings app, be sure to remove it before installing a kernel!
Download:
FTP
XDA:DevDB Information
Chrono Kernel Refresh, Kernel for the Samsung Galaxy S Advance I9070
Contributors
ChronoMonochrome, cocafe, faux123, zwliew, mkaluza, Meticulus, KINGbabasula, ace2nutzer, TeamCanjica
Source Code: https://github.com/ChronoMonochrome/Chrono_Kernel-1/commits/refresh-3.0.101
Kernel Special Features:
Version Information
Status: Testing
Stable Release Date: 1974-11-11
Beta Release Date: 1974-11-11
Created 2018-03-22
Last Updated 2018-03-23

Changelogs
Changelog
R4.6.2
rebased to CM14.1 branch (added support for 6.0.1 and 7.1.2 ROMs)
R4.6.1
fixed CPU OC instabilities
LCDCLK is adjusted to fix tearing issues *
adjusted Dynamic CPU governor tunables for a better battery live
adjusted PowerHAL profiles **
genfstab: storages swap is disabled by default (remove /ramdisk/fstab_specs.txt before flashing to take this change in an effect)
updated temporary kernel zip
* tested with apps like Impossible Game, a display tearings are mostly resolved here. Apps like Youtube, though, might still causing tearings when playing video.
** the minimum CPU freq is set to 400 MHz. I've decided to use it as a default since 200 and 400 MHz CPUfreq steps are anyway using the same voltage, so unless you're undervolting the CPU, there won't be any significant difference in a battery drain.
R4.6
updated to r4.6 LowMemoryKiller implementation - best so far!
Disabled HighMem
removed some CPUfreq steps *
Dynamic governor: parameters are tuned for the better performance (credits: @ace2nutzer)
Added performance profiles (the corresponding parameters can be found in /ramdisk/perf.profiles.rc)
Other updates from r4.6 (various updates from LK 3.4, tweaks etc)
* Avalable CPU frequency steps are: 200, 800, 1000, 1100, 1200, 1215 Mhz. I've decided just to give it a try - this is a necessary part of tuning the CPU governor. If anyone doesn't like that frequencies between 200 and 800 MHz were removed I can add them back, but until performance-related issues are not resolved I'd suggest just leave as it is.
R4.1
Initial build for janice (kernel sources based on Chrono Kernel r4.1)
LiveOPP: updated to r5.7.1 kernel version
Exfat: test fixes for Stock 4.1.2 ROM (not tested)
Enabled CONFIG_STE_TRACE_MODEM (test fix for Stock ROM incoming / outgoing calls)
Kexec: added janice support

Misc
Storages switch
By default, this kernel comes with internal and external storages switched. You can revert this behavior, by changing the line
Code:
use_swap=1
to
Code:
use_swap=0
in file /ramdisk/fstab_specs.txt and flashing the kernel package. This setting will remain until you format /ramdisk partition.

Thank you Chrono again.
So far I am still having issues with calls on 4.1.2 stock, I took another logcat in case would help you, and seems like phone can't enter deepsleep mode, but I will investigate further this issue with some days of usage.
I couldn't get exfat working, I took the exfat-fuse binary from /sbin in TWRP, then ran "exfat-fuse /dev/block/mmcblk1p1 /storage/extSdCard", tryed also with "mount.exfat-fuse etc etc", the fact is the card is correctly mounted and usable from recovery, but this does not matter after all.
The nice thing is I find multitasking working far better, phone seems to be more responsive in situations where more apps are running at the same time, this is very good to me!.
Another big point is installation went fine and recovery is working perfectly, so problems with possible bootloops are solved (and after some more usage I will go further to your more updated roms )
If there is something more to provide you, test or informations missing, please ask me Chrono

I tested chrono kernel r4.1 on Lineage OS 11.
-Compared to the previous chrono_kernel_r5.7.1, this is considerably slow, especially during the opening of apps like Settings, Contacts, Google News, Play store.
-If I set 1000 Mhz as maximum clock of the dynamic governor, the phone becomes slower and a bit hot on the back.
Multitasking is severely affected by that clock. Multitasking is more stable at 800 Mhz, despite it's still slow.
-If I reboot the phone, the maximum clock of 1000 Mhz is automatically resetted at 800 Mhz.
-If I attempt to reboot the phone in recovery mode from Lineage Os 11 ROM with the PC USB charging cable on, phone will shutdown instead. Disconnecting the charging cable before rebooting the phone in recovery mode is the only workaround. It doesn't happen with the Epirex Kernel, so I think it's related to your kernel.
In my attachment there is a meminfo that I took while the phone was under load.
If it isn't enough, I attached a full logcat. There are some errors and crashes.

@Pdevo, @isaak, thanks for testing!
I tested chrono kernel r4.1 on Lineage OS 11.
-Compared to the previous chrono_kernel_r5.7.1, this is considerably slow, especially during the opening of apps like Settings, Contacts, Google News, Play store.
Click to expand...
Click to collapse
Probably I've rushed things, or sort of. I had a hard time trying to find a considerably stable kernel 3.0.101 base (this one appeared to work stably, though not best, in terms of the performance). Nevertheless, the multitasking should already be better (at least better than in r5.7.1, as in this one LowMemoryKiller appeared not to work at all). I'm updating the sources to a new kernel base, r4.6 which should be even better in multitasking term.
-If I reboot the phone, the maximum clock of 1000 Mhz is automatically resetted at 800 Mhz.
Click to expand...
Click to collapse
Should be fixed in upcoming release.
-If I attempt to reboot the phone in recovery mode from Lineage Os 11 ROM with the PC USB charging cable on, phone will shutdown instead. Disconnecting the charging cable before rebooting the phone in recovery mode is the only workaround. It doesn't happen with the Epirex Kernel, so I think it's related to your kernel.
Click to expand...
Click to collapse
It's a bug in CM11 ramdisk, I've took another one from Codina, and now this issue should be resolved as well.
Pdevo said:
So far I am still having issues with calls on 4.1.2 stock, I took another logcat in case would help you, and seems like phone can't enter deepsleep mode, but I will investigate further this issue with some days of usage.
I couldn't get exfat working, I took the exfat-fuse binary from /sbin in TWRP, then ran "exfat-fuse /dev/block/mmcblk1p1 /storage/extSdCard", tryed also with "mount.exfat-fuse etc etc", the fact is the card is correctly mounted and usable from recovery, but this does not matter after all.
Click to expand...
Click to collapse
I'm afraid that exfat driver built in the kernel is not compatible with this userspace mount.exfat-fuse utility. I won't be able to fix it, until I find a time to return to stock & rebuild either mount.exfat-fuse or kernel driver in order to make them compatible each with other.
As for the deepsleep issue, I can say that at least 4.4.4 is not affected by this bug. Try making sure that no apps are preventing deep sleep (Better battery stats or Wakelock detector can help in that).

New build r4.6 is up!
Changelog
updated to r4.6 LowMemoryKiller implementation - best so far!
Disabled HighMem
removed some CPUfreq steps *
Dynamic governor: parameters are tuned for the better performance (credits: @ace2nutzer)
Added performance profiles (the corresponding parameters can be found in /ramdisk/perf.profiles.rc)
Other updates from r4.6 (various updates from LK 3.4, tweaks etc)
* Avalable CPU frequency steps are: 200, 800, 1000, 1100, 1200, 1215 Mhz. I've decided just to give it a try - this is a necessary part of tuning the CPU governor. If anyone doesn't like that frequencies between 200 and 800 MHz were removed I can add them back, but until performance-related issues are not resolved I'd suggest just leave as it is.

ChronoMonochrome said:
Changelog
updated to r4.6 LowMemoryKiller implementation - best so far!
Disabled HighMem
removed some CPUfreq steps *
Dynamic governor: parameters are tuned for the better performance (credits: @ace2nutzer)
Added performance profiles (the corresponding parameters can be found in /ramdisk/perf.profiles.rc)
Other updates from r4.6 (various updates from LK 3.4, tweaks etc)
* Avalable CPU frequency steps are: 200, 800, 1000, 1100, 1200, 1215 Mhz. I've decided just to give it a try - this is a necessary part of tuning the CPU governor. If anyone doesn't like that frequencies between 200 and 800 MHz were removed I can add them back, but until performance-related issues are not resolved I'd suggest just leave as it is.
Click to expand...
Click to collapse
Tested on Lineage Os 11 without CCleaner.
After flashing this new kernel I had to force a Media scan with Fx File Explorer (that detected over 300 changed files) because the phone was really slow. That was sufficient to speed up the multitasking that now it's much better than previous 4.1 build.
Additional observations:
- Do you think it's possible to improve Media scanner reactivity via kernel?
- Fx File Explorer detects my external sd card as Main storage and Media card as internal storage. This doesn't happen on Epirex kernel.
- Battery usage is higher than previous kernel. If I stay on a webpage in idle, after 30 seconds my battery decreases of one percentage point (i.e. from 70% to 69%). I noticed that a simple swipe on the screen jumps the current clock directly to the maximum frequency, this could be one of the reasons.
- There is only FIOPS as I/O Scheduler and I miss all the other schedulers.
I think you're on the right track!

isaak said:
- Do you think it's possible to improve Media scanner reactivity via kernel?
Click to expand...
Click to collapse
I don't think it's possible. The only possible way is to overclock CPU, though it won't help much.
- Fx File Explorer detects my external sd card as Main storage and Media card as internal storage. This doesn't happen on Epirex kernel.
Click to expand...
Click to collapse
This is a default behaviour in Chrono Kernel. Because on codina we have only 4 Gb of available space, it makes sense just to remove internal storage partition and use the external one as primary. If anyone wants, I can revert this behavior. It's possible to switch storages back by editing file /ramdisk/fstab_specs.txt (set use_swap value to 0) and flashing a kernel package.
- Battery usage is higher than previous kernel. If I stay on a webpage in idle, after 30 seconds my battery decreases of one percentage point (i.e. from 70% to 69%). I noticed that a simple swipe on the screen jumps the current clock directly to the maximum frequency, this could be one of the reasons.
Click to expand...
Click to collapse
Ok, I'll consider of tuning CPU governor in order to provide more battery friendly setup. I was afraid that the battery usage might be too high, but that was a necessary evil, I guess. In the meantime, as a temporary workaround, the maximum CPU frequency can even be lowered to 800 MHz, it should be still fast enough.
- There is only FIOPS as I/O Scheduler and I miss all the other schedulers.
I think you're on the right track!
Click to expand...
Click to collapse
To load more I/O schedulers, you can copy (or symlink) a module file to /system/lib/modules/autoload, then reboot the phone. This doesn't seem to work, a script that loads modules, is broken.
Because usually I don't change I/O scheduler, by default, no more I/O scheds are loaded. Do you have any preferred I/O scheds?

ChronoMonochrome said:
I don't think it's possible. The only possible way is to overclock CPU, though it won't help much.
Click to expand...
Click to collapse
Nevermind.
ChronoMonochrome said:
This is a default behaviour in Chrono Kernel. Because on codina we have only 4 Gb of available space, it makes sense just to remove internal storage partition and use the external one as primary. If anyone wants, I can revert this behavior. It's possible to switch storages back by editing file /ramdisk/fstab_specs.txt (set use_swap value to 0) and flashing a kernel package.
Click to expand...
Click to collapse
I'd like to revert the behavior, so I would appreciate If you could provide the same instructions here and in the other kernel thread..
ChronoMonochrome said:
To load more I/O schedulers, you can copy (or symlink) a module file to /system/lib/modules/autoload, then reboot the phone. This doesn't seem to work, a script that loads modules, is broken.
Because usually I don't change I/O scheduler, by default, no more I/O scheds are loaded. Do you have any preferred I/O scheds?
Click to expand...
Click to collapse
I would suggest deadline, noop, sioplus, zen (plus the existent FIOPS).

ChronoMonochrome said:
This is a default behaviour in Chrono Kernel. Because on codina we have only 4 Gb of available space, it makes sense just to remove internal storage partition and use the external one as primary. If anyone wants, I can revert this behavior. It's possible to switch storages back by editing file /ramdisk/fstab_specs.txt (set use_swap value to 0) and flashing a kernel package.
To load more I/O schedulers, you can copy (or symlink) a module file to /system/lib/modules/autoload, then reboot the phone. This doesn't seem to work, a script that loads modules, is broken.
Because usually I don't change I/O scheduler, by default, no more I/O scheds are loaded. Do you have any preferred I/O scheds?
Click to expand...
Click to collapse
Personally I really appreciate and find useful the external sdcard storage as primary one, should be the default behaviour for me, it makes sense and also I never liked to have some files on one unit and some files on another one (download, pictures, recordings on extsdcard, apps folders, screens, other apps downloads etc on internal), I really like the idea of sdcard as main, like the old times of galaxy mini
Fiops to me is a fair good scheduler, maybe also noop would be useful, but I guess having as much things as modules as possible can help load only the strictly necessary, but I say this without dev knowledge.
I will test this build and especially the deepsleep issues, to see if there are apps causing phone not to sleep, the problem is I didn't add any app, just using the same enviroment that with cocore was going to deepsleep. I will report soon, anyway, good job chrono, keep it up

Pdevo said:
Fiops to me is a fair good scheduler, maybe also noop would be useful, but I guess having as much things as modules as possible can help load only the strictly necessary, but I say this without dev knowledge.
Click to expand...
Click to collapse
Yes, FIOPS is good. I just think that having 2 or 3 additional schedulers to select would be better for different uses.
In my previous post I replaced sioplus with zen, according to the conclusions of this guide. There is an useful (up to date) list of recommended IO schedulers, ordered for everyday usage, battery life, heavy multitasking, etc.

New build r4.6.1 is up!
Hey guys and sorry for having to wait that long for a new releases!
I'm still working on 3.4.x kernel - no great news here, but at least I've found a more less stable sources base, so the only what needed now, is a time to bring up some stability fixes and feature changes.
For now releasing a 3.0.101 kernel with some minor changes:
R4.6.1
fixed CPU OC instabilities
LCDCLK is adjusted to fix tearing issues *
adjusted Dynamic CPU governor tunables for a better battery live
adjusted PowerHAL profiles **
genfstab: storages swap is disabled by default (remove /ramdisk/fstab_specs.txt before flashing to take this change in an effect)
updated temporary kernel zip
* tested with apps like Impossible Game, a display tearings are mostly resolved here. Apps like Youtube, though, might still causing tearings when playing video.
** the minimum CPU freq is set to 400 MHz. I've decided to use it as a default since 200 and 400 MHz CPUfreq steps are anyway using the same voltage, so unless you're undervolting the CPU, there won't be any significant difference in a battery drain.

ChronoMonochrome said:
** the minimum CPU freq is set to 400 MHz. I've decided to use it as a default since 200 and 400 MHz CPUfreq steps are anyway using the same voltage
Click to expand...
Click to collapse
On Lineage OS 11:
Using more accurately the Performance function in Lineage Os Settings (an example here), there are different bugs:
1) Minimum CPU freq here is still set at 200 MHz after I flashed chrono kernel 4.6.1.. but this time I forgot to flash the temporary kernel before your kernel.
Anyway chrono kernel 4.6.1 was flashed without issue using TWRP 2.8.7.0.
2) Maximum CPU freq is automatically restored at 1000 Mhz after any reboot, even if I set 1200 Mhz (with any governor).
3) Deadline scheduler is automatically set after any reboot, even if I set FIOPS as default scheduler.
4) Dynamic governor is automatically set after any reboot, even if I set Zenx as default governor.
5) On the Performance UI, performance profile results automatically set on Balanced after any reboot, even if I set Power save as default (it may be reproducible with "Performance" option too, I didn't check).
UPDATE: I've reinstalled chrono kernel again and these behaviors still happen.

For me the minimum freq was correctly 400 mhz as expected, as always running on stock 4.1.2.
After two days of use I can say you are following the right path.
This time I wanted to remove every possible source of doubts and I went for a clean installation, so doing a complete reset and flashing your kernel, of course after the temporary one. I still have the phone not going to deepsleep and the call issues (basically it is impossible to do and receive phone calls on stock rom).
A part from these I can say I didn't noticed any other issue at all, finding memory management a little improved compared to previous release and battery life still good, considering the phone isn't going to sleep mode.
I think this will continue to improve and soon all these glitches will just be gone away, thank you so much chrono also hoping to settle for a bit on your ultimateROM, only waiting for the vibration working, because that is basically the only notification for me

isaak said:
On Lineage OS 11:
Using more accurately the Performance function in Lineage Os Settings (an example here), there are different bugs:
1) Minimum CPU freq here is still set at 200 MHz after I flashed chrono kernel 4.6.1.. but this time I forgot to flash the temporary kernel before your kernel.
Anyway chrono kernel 4.6.1 was flashed without issue using TWRP 2.8.7.0.
2) Maximum CPU freq is automatically restored at 1000 Mhz after any reboot, even if I set 1200 Mhz (with any governor).
3) Deadline scheduler is automatically set after any reboot, even if I set FIOPS as default scheduler.
4) Dynamic governor is automatically set after any reboot, even if I set Zenx as default governor.
5) On the Performance UI, performance profile results automatically set on Balanced after any reboot, even if I set Power save as default (it may be reproducible with "Performance" option too, I didn't check).
UPDATE: I've reinstalled chrono kernel again and these behaviors still happen.
Click to expand...
Click to collapse
1) Isn't an issue here, the showed CPU frequency is 200 MHz, but the actual CPU pll clock set at 400 MHz. Might be confusing, but yet that is better for a battery life.
2) These aren't really bugs, it's how LOS 11.0 performance profiles works. To change min / max CPU freq, you either need to edit /ramdisk/perf.profiles.rc (and set a custom values) or disable perf profiles. Actually there is one more way - to remove CPUfreq adjusting lines completely from that script - would anyone like this change introduced in a new release?
3-4) I've checked it right now - no issues for me... Have you set "apply on boot" checkbox?
5) It's a known bug of CM11 perf profiles. AFAIK, @ace2nutzer fixed this bug in his CM11 builds. @ace2nutzer, can you please remind how this could be worked around?

ChronoMonochrome said:
2) Maximum CPU freq is automatically restored at 1000 Mhz after any reboot, even if I set 1200 Mhz (with any governor).
Click to expand...
Click to collapse
2) These aren't really bugs, it's how LOS 11.0 performance profiles works. To change min / max CPU freq, you either need to edit /ramdisk/perf.profiles.rc (and set a custom values) or disable perf profiles. Actually there is one more way - to remove CPUfreq adjusting lines completely from that script - would anyone like this change introduced in a new release?
Click to expand...
Click to collapse
Honestly I don't know how to disable perf profiles. If it's a simple thing to do (like a command or two to execute), please tell me how to do it because it's enough for me, otherwise I'd like to try the third way and see.
ChronoMonochrome said:
3) Deadline scheduler is automatically set after any reboot, even if I set FIOPS as default scheduler.
4) Dynamic governor is automatically set after any reboot, even if I set Zenx as default governor.
Click to expand...
Click to collapse
3-4) I've checked it right now - no issues for me... Have you set "apply on boot" checkbox?
Click to expand...
Click to collapse
Yes, "Set on boot" options are correctly set for both Processor and I/O Scheduler.
And I keep "Enable per-app profiles" option turned off.
@ChronoMonochrome
UPDATE 1: It occurs only randomly and with particular combinations. The best way to reproduce is to set these, one at a time:
1) Zenx as governor, min. 200 max 800, Noops scheduler. Reboot.
2) Zenx as governor, min. 200 max 800, Fiops scheduler. Reboot.
2) Zenx as governor, min. 200 max 800, Sioplus scheduler. Reboot.
After the first, the second or the third reboot, some of these values you've set will change spontaneously on their own.
UPDATE 2: I've got a screen flicker issue while I was browsing in Naked Browser with the new LCDCLK frequency.
Tried to set echo 1 > /sys/kernel/mcde/lcdclk, it's ok now, but I've noticed that this value is not kept after a reboot.
Do you need a specific log?
In case please write me any command and I'll give you the output.

isaak said:
On Lineage OS 11:
Using more accurately the Performance function in Lineage Os Settings (an example here), there are different bugs: .....
Click to expand...
Click to collapse
I suggest to keep it unchecked, otherwise it'll change the profile randomly, and that's probably not what u want.
ChronoMonochrome said:
....
5) It's a known bug of CM11 perf profiles. AFAIK, @ace2nutzer fixed this bug in his CM11 builds. @ace2nutzer, can you please remind how this could be worked around?
Click to expand...
Click to collapse
There's still no fix ! But what i did is to add the perf. profile in my control app ... that works fully independently.
But that's probably not what u guys want.
My last try was to do that over build.prop .. this works only for around 15 seconds (after wiping dalvik cache it's around 30 sec.) and then it sets back to "balanced" .. so i use it anyway just for speeding up the boot sequence:
Code:
# CM Performance Profiles (only during boot)
# 0= powersave; 1= balanced; 2= performance - default
sys.perf.profile=2
IMO the best way is to add the perf. profiles button to the quick settings, then it's very easy to switch between the 3 profiles.
Using the same profile for everything is for sure not the best option if u want performance + powersave at the same time.
Personally i use performance, and when i read an pdf or watch a YouTube Video then i switch to powersave.
Using powersave or even balanced for normal usage isn't recommended as it can drain even more battery than using performance, because it's slower and the CPU will stay too long on max. freq and the LCD also will stay longer ON, which leads both to increase power consumption.
So the faster the cpu is, the quicker it'll go on idle (min cpu 200) which is powersaving freq and the faster u'll turn OFF the screen, and logical bigger time on suspend --> deep sleep :highfive:

ace2nutzer said:
I suggest to keep it unchecked, otherwise it'll change the profile randomly, and that's probably not what u want.
There's still no fix ! But what i did is to add the perf. profile in my control app ... that works fully independently.
But that's probably not what u guys want.
My last try was to do that over build.prop .. this works only for around 15 seconds (after wiping dalvik cache it's around 30 sec.) and then it sets back to "balanced" .. so i use it anyway just for speeding up the boot sequence:
Code:
# CM Performance Profiles (only during boot)
# 0= powersave; 1= balanced; 2= performance - default
sys.perf.profile=2
IMO the best way is to add the perf. profiles button to the quick settings, then it's very easy to switch between the 3 profiles.
Using the same profile for everything is for sure not the best option if u want performance + powersave at the same time.
Personally i use performance, and when i read an pdf or watch a YouTube Video then i switch to powersave.
Using powersave or even balanced for normal usage isn't recommended as it can drain even more battery than using performance, because it's slower and the CPU will stay too long on max. freq and the LCD also will stay longer ON, which leads both to increase power consumption.
So the faster the cpu is, the quicker it'll go on idle (min cpu 200) which is powersaving freq and the faster u'll turn OFF the screen, and logical bigger time on suspend --> deep sleep :highfive:
Click to expand...
Click to collapse
Sorry for so late response, I had to take a break in a development because suddenly got sick with a flu (I'm fine now, btw) :silly:
I think I've found a temporary solution to this bug, take a look if you're interested:
https://github.com/ChronoMonochrome...mmit/bd0dcce403633543f1bf11e5f8b476a3e88322cb

New build is up!
Changelog
R4.6.2
rebased to CM14.1 branch (added support for 6.0.1 and 7.1.2 ROMs) *
Hey there! I've been testing 6.0.1 / 7.1.2 ROMs and I've recently got some issues with camera on 3.4.x kernel build, so I've decided to release a new refresh build (based on 3.0.101 sources).
I've rebased the most of recent changes to CM14.1 branch in order to support these ROMs (so if you're using older ROMs like stock 4.1.2 then better to use previous release cause some patches might be missing here).

Database Users

welcome