I am trying to write a script to switch the i/o scheduler to sio. I am misticninja's kernel (that has the sio scheduler, init.d support) and following this guide
http://forum.xda-developers.com/showthread.php?t=1473921
but the script doesn't seem to work.
I can run it manually from the /system/etc/init.d driectory after I boot but it won't run at boot on its own and defaults to noop.
What am I missing here? Is there something different about the Asus Transformer in regard to init.d scripts? Does the script need to have a specific name?
Sent from my Transformer TF101 using Tapatalk
Any luck yet? I was able to get it to work. I put the script in /system/etc/init.d and called it sioscheduler then set the permissions to 755 ( rwxr-xr-x ) using File Manager HD.
I tried out misticninja's kernel and the script did not work but it does work with TestyMeh.
I sort of gave up I am using guevor's kernel now I will try it again.
EDIT: Looks like it works with guevor's kernel and megatron rom
Related
cpufreq: interactive: New 'interactive' governor
New interactive governor.
This governor is designed for latency sensitive workloads, UI interaction for
example.
Advantages:
+ significantly more responsive to ramp cpu up when required (UI interaction)
+ more consistent ramping, existing governors do their cpu load sampling in a
workqueue context, the 'interactive' governor does this in a timer context, which
gives more consistent cpu load sampling.
+ higher priority for cpu frequency increase, rt_workqueue is used for scaling
up, giving the remaining tasks the cpu performance benefit, unlike existing
governors which schedule rampup work to occur after your performance starved
tasks have completed.
Existing governors sample cpu load at a particular rate, typically
every X ms. Which can lead to under powering UI threads when the user has
interacted with an idle system until the next sample period happns.
The 'interactive' governor has a different approach. Instead of sampling the cpu
at a specified rate, the governor will scale the cpu frequency up when coming
out of idle. When the cpu comes out of idle, a timer is configured to fire
within 1-2 ticks. If the cpu is 100% busy from exiting idle to when the timer
fires then we assume the cpu is underpowered and ramp to MAX speed.
If the cpu was not 100% busy, then the governor evaluates the cpu load over the
last 'min_sample_rate' (default 50000 uS) to determine the cpu speed to ramp down
to.
There is only one tuneable for this governor:
/sys/devices/system/cpu/cpufreq/interactive/min_sample_rate:
The minimum ammount of time to spend at the current frequency before
ramping down. This is to ensure that the governor has seen enough
historic cpu load data to determine the appropriate workload.
Default is 5000 uS.
Click to expand...
Click to collapse
Load the module with:
Code:
insmod /system/lib/modules/cpufreq_interactive.ko nr_running_addr=0x`grep nr_running /proc/kallsyms|cut -c1-8`
Activate governor with:
Code:
echo "interactive" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
Well, this seems promising, however, when loading the module with the command you gave, I got something in the lines of:
insmod init fail wrong argument
Click to expand...
Click to collapse
Either way, I loaded it with the command insmod cpufreq_interactive.ko and set the governor, however, cpu frequency seems to be stuck at 998MHz?
Any thoughts?
You have to provide the "nr_running_addr" parameter with the correct memory addr. Try grepping the addr with:
Code:
grep nr_running /proc/kallsyms|cut -c1-8
This should return something like c0057280. Provide this on insmod to kernel module:
Code:
insmod /system/lib/modules/cpufreq_interactive.ko nr_running_addr=0xc0057280
Without the correct nr_running_addr the module most likely won`t work!
Works fine here!
Do I have to execute those commands every time I reboot?
You can use the example init script included in zip. It executes the needed command on boot...
Ok... got it.
Might wanna add that you have to push that script to /system/etc/init.d/
The powersave governor...
tun.ko module
Hi,
thanks for the modules. I need the tun.ko module for this kernel. Can you provide it please. Or can you tell me how to get to the sources of this kernel, or is there a list of all compiled modules where it can be downloaded.
Thanks in advance
Regards
Roger
Attached all modules I use on 2.6.32.15-gf9c0527...
Good! Thanks for your work
+10
any chance for OC : )
Yes, if you are kernel hacker and have enough knowledge, you could spend some time at http://code.google.com/p/milestone-overclock/wiki/Disassembly and write a module for HTC kernels.
Or just wait for HTC to release the kernel source...
how do i apply the powersave governor
i have the insmod command into the init.d scripts.....
the interactive governor gets detected by setcpu but the powersave does not....how do i activate it and what's the difference ????
lambrospower said:
how do i apply the powersave governor
i have the insmod command into the init.d scripts.....
the interactive governor gets detected by setcpu but the powersave does not....how do i activate it and what's the difference ????
Click to expand...
Click to collapse
Would I be correct in saying that you need to edit the script to have:
echo "powersave" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
below the 'insmod' command? I am not 100% sure and too tired to test right now, but I plan to use ADB (for the first time finally!) to push these .ko modules to /system/lib/modules, and their scripts to /system/etc/init.d/. I hope this method will make the .ko module active on boot, and then I can switch to use it (interactive OR powersave) in SetCPU. Please let me know if I am correct.
Also, can someone please confirm my suspicions that I need to push these files while in Recovery mode? (hence, getting rw access to /system).
Thanks in advance!
no i fixed it yesterday,....you just have to insmod the powersave module....then it's selectable in setcpu
Heya FloHimself,
Thanks for this new governor. I am excited to use it, however I am having some problems activating it. As I said in my previous post, I have not used ADB before to push files, however I just did it, and it appears to work successfully, but SetCPU does not show me the Interactive OR Powersave governors...below is what I did:
1. Booted to Clockwork Recovery
2. Went to PARTITIONS --> Mount System
3. Plugged in USB cable
4. Ran "ADB remount"
5. Pushed the .ko modules to /system/lib/modules
6. Pushed the scripts to /system/etc/init.d
7. Verified existence of files by running ADB shell, then LS /system/lib/modules + /system/etc/init.d
Code:
C:\android-sdk-windows\tools>adb shell
~ # ls /system/lib/modules
ls /system/lib/modules
bcm4329.ko cpufreq_powersave.ko tun.ko
cpufreq_interactive.ko perflock_disable3215.ko
~ # ls /system/etc/init.d
ls /system/etc/init.d
02cachedalvikcache 40cpufreq_powersave 99complete
30cpufreq_interactive 90fixes
40a2sd 97perflock
~ # exit
exit
8. Saw the files were there, so disconnected my Desire
9. Unmounted /system back in Clockwork Recovery
10. Rebooted.
Upon getting back into Android, I used ES File Explorer to browse to the /system/lib/modules + /system/etc/init.d folders and indeed saw the 4 files that I pushed (2 .ko and 2 scripts). After rebooting a few times, I still cannot get SetCPU to see these governors, it's just the default 3 of "userspace / ondemand / performance".
Is there something that I'm missing? I am surely running a rooted FroYo ROM (LeeDroid v1.8a to be exact, with the OTA 2.6.32.15-gf9c0527 kernel) and I believe I pushed the files correctly.
Any guidance or tips would be greatly appreciated!
Thanks in advance!
Many thanks for this
Got both running powersave and interactive... Is there a explaination how they scale?
xtcislove said:
Many thanks for this
Got both running powersave and interactive... Is there a explaination how they scale?
Click to expand...
Click to collapse
The first post has a pretty good explanation of how the interactive module works, but yea I guess it's hard to tell how they scale (could be two different things...working and scaling)...
I really want to use this but am at a stand still as per my post above...xtcislove, how exactly did you install+activate them? I don't know what I could have done wrong in my methods above...
** EDIT ** - OK I am making some headway here...I have installed the module and script fine, however they weren't getting executed on boot. I then connected back to ADB SHELL, then manually ran the commands from the first/original post. After that, SetCPU shows the Interactive governor! It works great because it stays at 245mhz constant (when idle) and doesn't jump up and down like the "ondemand" one.
Now I just need some help with getting these commands to run automatically upon system startup. I thought that having the script in the /system/etc/init.d folder would mean that it gets run when the system starts, but it doesn't appear to do so...
Many thanks to anyone who can help...I'm so close and I feel that battery life will be greatly improved!
There should be an entry in /init.rc to run the stuff from etc/init.d. However, if it's missing, there is an unused script, started automatically by init: /system/etc/install-recovery.sh. Of course, it's misssing in (at least official) HTC ROMs, but that's the good news. Just put there a script to execute run-parts /system/etc/init.d. A script like this will work:
Code:
#!/system/bin/sh
# hook into the system startup sequence, /system/etc/install-recovery.sh
CM_FILESYSTEM_READY=$(getprop cm.filesystem.ready)
if [ "x$CM_FILESYSTEM_READY" = "x" ]; then
BUSYBOX=/system/xbin/busybox
if [ -x "$BUSYBOX" ]; then
SYSINITDIR=/system/etc/init.d
if [ -d "$SYSINITDIR" ]; then
log -t SysInit "Starting sysinit scripts from $SYSINITDIR"
/system/bin/logwrapper "$BUSYBOX" run-parts "$SYSINITDIR"
fi
else
log -p e -t SysInit "No $BUSYBOX found, skipping sysinit"
fi
else
log -p w -t SysInit 'sysinit is already completed, skipping'
fi
# EOF
Put it on your device via recovery (adb shell mount /system; adb push install-recovery.sh /system/etc; adb shell chmod 755 /system/etc/install-recovery.sh).
how do i make this file with a txt-editor
or can you make this file for me and upload it here
can i push the files through android commander
so after searching the forums i found:
1) faux clock
2) system tuner
3) init.d scripts
with (2) vdd values dont persist & revert to stock after a while for some unknown reason.
with (3) the vdd table doesnt change at all, except when the same commands in script are entered through adb.
i havent tried (1). i've had the most success with (3), but having to do it through adb every reboot is a bother. how are you guys doing it?
kaof said:
so after searching the forums i found:
1) faux clock
2) system tuner
3) init.d scripts
with (2) vdd values dont persist & revert to stock after a while for some unknown reason.
with (3) the vdd table doesnt change at all, except when the same commands in script are entered through adb.
i havent tried (1). i've had the most success with (3), but having to do it through adb every reboot is a bother. how are you guys doing it?
Click to expand...
Click to collapse
I'm using FauxClock 0.8.0 and resetting if it reboots.
I like the fact that it resets the UV on a boot, so that if I've UV'd too low it resets to be usable on a boot.
gol_n_dal said:
I'm using FauxClock 0.8.0 and resetting if it reboots.
I like the fact that it resets the UV on a boot, so that if I've UV'd too low it resets to be usable on a boot.
Click to expand...
Click to collapse
I think fauxclock 0.8 is your best option. 0.75 has some compatibility problem so do not use it.
If you want to use a scrip. I would put the corresponding code in the /etc/init.post_boot.sh
Code:
echo "-50000" > /sys/devices/system/cpu/cpufreq/vdd_table/vdd_levels
Reboot and then check the vdd table.
If init.post_boot.sh does not exist, do the following in the terminal emulator
Code:
touch /system/etc/init.post_boot.sh
chmod a+x /system/etc/init.post_boot.sh
vi /system/etc/init.post_boot.sh
After successfully creating the init.post_boot.sh, then write this in it:
Code:
#!/system/bin/sh
<YOUR COMMANDS GO HERE>
gol_n_dal said:
I'm using FauxClock 0.8.0 and resetting if it reboots.
I like the fact that it resets the UV on a boot, so that if I've UV'd too low it resets to be usable on a boot.
Click to expand...
Click to collapse
Scripts make a cleaner mod, try it someday!
You can UV individual frequencies, and after you get it right it's just set-it-and-forget-it.
yungyeh said:
I think fauxclock 0.8 is your best option. 0.75 has some compatibility problem so do not use it.
If you want to use a scrip. I would put the corresponding code in the /etc/init.post_boot.sh
Code:
echo "-50000" > /sys/devices/system/cpu/cpufreq/vdd_table/vdd_levels
Reboot and then check the vdd table.
If init.post_boot.sh does not exist, do the following in the terminal emulator
Code:
touch /system/etc/init.post_boot.sh
chmod a+x /system/etc/init.post_boot.sh
vi /system/etc/init.post_boot.sh
After successfully creating the init.post_boot.sh, then write this in it:
Code:
#!/system/bin/sh
<YOUR COMMANDS GO HERE>
Click to expand...
Click to collapse
Lesson learnt - UV scripts in system/etc/init.d don't work, but editing init.post_boot.sh does!
Works like a charm, thanks so much!
kaof said:
Lesson learnt - UV scripts in system/etc/init.d don't work, but editing init.post_boot.sh does!
Works like a charm, thanks so much!
Click to expand...
Click to collapse
Have to make sure that the init.d scripts have the right permissions for them to work ^_^
Kohr-Ah said:
Have to make sure that the init.d scripts have the right permissions for them to work ^_^
Click to expand...
Click to collapse
What are the right permissions?
I tried
Code:
adb shell
chmod 777 system/etc/init.d/scriptName
and it didn't work!
Hello,
I want to change my voodoo colors at boot, so I made a script in init.d folder:
Code:
#!/system/bin/sh
echo 2447339790 >/sys/devices/virtual/misc/voodoo_color/red_multiplier
echo 2159029280 >/sys/devices/virtual/misc/voodoo_color/green_multiplier
echo 2782492160 >/sys/devices/virtual/misc/voodoo_color/blue_multiplier
echo -14 >/sys/devices/virtual/misc/voodoo_color/red_v1_offset
echo -17 >/sys/devices/virtual/misc/voodoo_color/green_v1_offset
echo -18 >/sys/devices/virtual/misc/voodoo_color/blue_v1_offset
And here is my init.d folder : http://i.imgur.com/nhkdy.png , 99voodoo is my script.
When I paste this codes to android terminal emulator, it is working flawlessly.
But it does not work in init.d folder. Tried different roms which support init.d scripting, but no luck.
What is wrong with it? Can anyone help?
Thanks.
I had the same issue with couple of kernels not sure why im prety sure they even support (Eugene and glados)
you have to set full permissions on the script also but still didn't work for me
I gave up and just used ROM toolbox and made it run at startup works no problem
There must be a solution. What am I doing wrong!?
Do you have Busybox installed?
Hostile89 said:
Do you have Busybox installed?
Click to expand...
Click to collapse
Yes, preinstalled with the rom I've been using:
http://forum.xda-developers.com/showthread.php?t=1397358
features "root, busybox, zipalign, Bash, init.d scripts ... etc".
Any help? No solution?
What is your ROM and kernel combination?
I was using Aosp+ Rom and ICUP-Speedy-3 kernel.
Now, I have just flashed CyberGR rom. Comes with GLaDOS 2.7 kernel. Feature list says "Init.d scripts support", but no luck for me. My script doesn't work with this rom too. What is wrong with it :S
I found the solution.
I was trying to move my script to init.d folder manually via RootExplorer app.
But pushing the same file via adb just worked.
Thanks to this: http://forum.xda-developers.com/showthread.php?t=1424032
Can anyone confirm that UC V9 kernel has proper support for init.d scripts? I have tried several scripts and checked the values through terminal emulator and it seems that none of the scripts are executed. I'm on stock KPQ with UC V9 kernel.
Thanks a lot!
I can't test it because I'm not currently using UC kernel, but are you sure that those scripts are executable or that there aren't other scripts that override your settings? When I used it (an older version) they worked.
Code:
ls -l /etc/init.d
This will show a list all your scripts with their permissions. They should be
Code:
rwxr-xr-r
Or try to execute one of the scripts and see if the values you want to change effectively change.
UC kernel V9 has support for init.d scripts! As they said.
And, I did test it with a older version!
Sent from my I9100 using XDA app
I've tried repeatedly and finally I've realised that it was the scripts that were not working. UC V9 kernel supports scripts seemlessly via /system/etc/init.d.
Thank you guys for your replies!
I've been running the ElementalX kernels on HatkaXL Rom, and they run fine, but they don't seem to be applying any of the custom settings using /etc/init.d/99elementalx. If I run it manually (using adb shell), it does work (loads all the modules, can see them using lsmod, and also adds the cpu governers, which I can see in kernel tuner).
I've been trying to figure out why my init.d script isn't running, and I'm stuck. Here's what I've tried:
* Flash boot.img manually using fastboot
* Update permissions to init.d scripts manually (they're all a+rwx and owned by root:root)
* boot boot.img manually (fastboot boot boot.img)
All of these methods fail in running my init.d scripts. As far as I can tell the init.rc inside the boot image is running the init scripts correctly (using run-parts).
Why aren't my init.d scripts running?
Any pointers on how to debug this further would be greatly appreciated.
I'm using one of the first batches of One XL's (AT&T) and am still running hboot 1.09.
I don't know anything about this stuff but I know having cpu app like kernel tuner set to run at boot can cause problems.
Sent from my VenomXL using Xparent Red
ImagioX1 said:
I don't know anything about this stuff but I know having cpu app like kernel tuner set to run at boot can cause problems.
Sent from my VenomXL using Xparent Red
Click to expand...
Click to collapse
Ah, I should have added that I disabled Kernel Tuner running at boot, and merely use it to verify my cpu settings/tweaks are indeed applied.
thatdutchguy said:
I've been running the ElementalX kernels on HatkaXL Rom, and they run fine, but they don't seem to be applying any of the custom settings using /etc/init.d/99elementalx. If I run it manually (using adb shell), it does work (loads all the modules, can see them using lsmod, and also adds the cpu governers, which I can see in kernel tuner).
I've been trying to figure out why my init.d script isn't running, and I'm stuck. Here's what I've tried:
* Flash boot.img manually using fastboot
* Update permissions to init.d scripts manually (they're all a+rwx and owned by root:root)
* boot boot.img manually (fastboot boot boot.img)
All of these methods fail in running my init.d scripts. As far as I can tell the init.rc inside the boot image is running the init scripts correctly (using run-parts).
Why aren't my init.d scripts running?
Any pointers on how to debug this further would be greatly appreciated.
I'm using one of the first batches of One XL's (AT&T) and am still running hboot 1.09.
Click to expand...
Click to collapse
I haven't used that rom, does it have busybox? Does 99elementalx have execute permissions (eg: chmod 777 /etc/init.d/99elementalx)
There is an easier workaround. Edit /etc/init.qcom.post_boot.sh and add /system/etc/init.d/99elementalx at the very bottom. Ensure init.qcom.post_boot.sh has execute permission.
flar2 said:
I haven't used that rom, does it have busybox? Does 99elementalx have execute permissions (eg: chmod 777 /etc/init.d/99elementalx)
There is an easier workaround. Edit /etc/init.qcom.post_boot.sh and add /system/etc/init.d/99elementalx at the very bottom. Ensure init.qcom.post_boot.sh has execute permission.
Click to expand...
Click to collapse
I'll try that. I added busybox myself (I think it was already on there too though) and permissions seem to all be right. It even loads the wp_mod, but I can't figure out where it loads it.
Stay tuned to see if that worked
*update*
I added:
Code:
busybox run-parts /system/etc/init.d
to my /system/etc/init.qcom.post_boot.sh, and that solved my problem.
Still wonder why it was not running init.d to begin with, since I see a similar snippet in init.rc (inside the boot.img).