Database Develop

[KERNEL] Building additional modules for JB stock kernels

Some background info:
I'm the author of PPP Widget which is an app that enables mobile data connections on Android devices with USB host capabilities - even if they are WiFi-only.
It turned out that many Android devices have the drivers for 3G sticks already on board, included with the stock kernel. The one large exception are Samsung devices ...
I started to provide the missing drivers as modules (mostly "ppp_async" and "option" which depends on "usb_wwan"). That worked well for some Google devices and also for Samsung devices running ICS, using the source packages from
http://opensource.samsung.com/
In their JB kernels though, Samsung enabled the "MODVERSION" option. Furthermore, compiling the modules with the officially recommended toolchain resulted in a different "module_layout" checksum than in the modules provided in the firmware.
This prevents using any additonal modules on the devices. "insmod" refuses to load these modules.
The only explanation for this problem is that the custom device configuration provided in the source packages does not match the configuration of the device kernel.
This is the case for all GT-P31xx and GT-P51xx models as far as I can tell.
My take is that Samsung is required to provide the correct kernel configuration under the rules of the GPL. Maybe anyone else wants to contact Samsung on this behalf; I already did several times - still waiting for an answer ...

That's the reason why I build everyting from source including the GPU driver and lost exFAT support http://forum.xda-developers.com/showthread.php?t=1859227 and the boot image result http://forum.xda-developers.com/showthread.php?t=1855700 .

ketut.kumajaya said:
That's the reason why I build everyting from source including the GPU driver and lost exFAT support
Click to expand...
Click to collapse
Unfortunately, replacing the kernel is no option for end users. The modules I provide are going into a folder on the sdcard, and can be "insmod'ed" from there with no problem - once their magic string and the "modversions" are matching the kernel on the device. The latter is the wall I'm hitting ...

JFDee said:
Unfortunately, replacing the kernel is no option for end users. The modules I provide are going into a folder on the sdcard, and can be "insmod'ed" from there with no problem - once their magic string and the "modversions" are matching the kernel on the device. The latter is the wall I'm hitting ...
Click to expand...
Click to collapse
Thanx alot for such a great development. ...
Adi™
Creator Of Sungsonic™HD

I have received a reply from Samsung. They have updated the JB open source package for GT-P3110, GT-P5110 and GT-N7100 (which previously included a config file from 3.0.15 for a kernel version of 3.0.31 !!).
Unfortunately, the modversions of the compiled kernel are still different and incompatible. I have replied with these finding.
Waiting again ...
BTW, the only recent kernel config consistent with the actual device kernel that I have found is for the GT-N8000 (3.0.31). So it is possible to provide a matching configuration.

JFDee said:
I have received a reply from Samsung. They have updated the JB open source package for GT-P3110, GT-P5110 and GT-N7100 (which previously included a config file from 3.0.15 for a kernel version of 3.0.31 !!).
Unfortunately, the modversions of the compiled kernel are still different and incompatible. I have replied with these finding.
Waiting again ...
BTW, the only recent kernel config consistent with the actual device kernel that I have found is for the GT-N8000 (3.0.31). So it is possible to provide a matching configuration.
Click to expand...
Click to collapse
If You will start to work with kernel I'm willing to beta test with my P5110. Only issue for me is that I need to know what 3G dongle to buy (well need it anyway so would prefer an advice from someone who know something about it). I'm living in Poland and Ireland (once here once there) so I can even test LTE modems (well donations here, myself can spend up to ~50€ on 3G one) because in Wroclaw, Poland I heard it's quite good, also I got H+/H on SGSII here. While in Ireland signal is not THAT strong due to fact most of places are quite remote (except Dublin, Galway etc). Hope I can help in either way

This is what I wrote to Samsung concerning the botched configuration file provided with the latest GT-P3110 kernel source:
Thank you for the source code update.
However, I have asked for the kernel configuration that matches exactly the kernel on the GT-P3110.
I have compiled the kernel from the provided update, but the module layout checksum does *not* match the one from the kernel running on my device.
On the device: module_layout 0xb5a27644
From source: module_layout 0x143474f1
I have used the recommended toolchain "CodeSourcery 2010q1" and the unchanged config file provided with the source ("android_espresso_omap4430_r04_user_defconfig").
Please be aware that you are obliged by the GPL to provide the correct config file for the binary kernel that you are distributing.
As a side note: the configuration provided with the kernel source for the GT-N8000 *does* match the kernel on the device, so there is no doubt that it is possible to get the configuration right.
Other Android vendors are just enabling the "embedded" config file in the kernel, so that the correct configuration is simply available on the device as "/proc/config.gz". This is so much less trouble. I suggest that you enable this option for Samsung kernels too.
Regards,
...
Click to expand...
Click to collapse

The GT-N8010 is also in the same situation you describe - config for 3.0.15 and jb stock kernel at 3.0.31, can't build working modules for stock.

davp, there seems to have been some activity at the Samsung open source center after my messages.
I suggest you make yourself heard as well. Use the "Inquiry" button next to the package download link in the table for your device.
To be able to add working modules to the device, the kernel configuration for the source has to be 100% compatible. It does not matter if any closed drivers are missing as we don't want to replace the kernel - but all those general debugging config options should be correct.
BTW, there is a history of similar issues:
http://forum.xda-developers.com/showthread.php?t=1123643

The kernel source for the GT-P3110 has been updated once more, and this time they have fixed the configuration.
With the latest JB update we can actually build working modules for the current firmware.
I confirmed this to the Samsung people and reminded them of the other devices in need of this fix: GT-P3100, GT-P5100, GT-P5110, GT-N7100 and probably more (like the GT-N8010).

JFDee said:
The kernel source for the GT-P3110 has been updated once more, and this time they have fixed the configuration.
With the latest JB update we can actually build working modules for the current firmware.
I confirmed this to the Samsung people and reminded them of the other devices in need of this fix: GT-P3100, GT-P5100, GT-P5110, GT-N7100 and probably more (like the GT-N8010).
Click to expand...
Click to collapse
So for now we might get stock kernel which will support 3G modems via USB OTG? How about other kernels such as CM10.1?
I'm looking for good 3G dongle then Any advices?

Additional kernel modules for stock JB P31xx (tested) and P51xx (untested), contains:
- usb_wwan, ppp_async, and option module for PPP Widget
- dns_resolver, md4, and cifs module for cifs/samba filesystem support
- sunrpc, lockd, and nfs module for nfs filesystem support
Kernel config file attached.

FTDI Single Port Serial Driver added.

cifs.ko not working on P3100 JB 4.1.2 (stock rooted)
ketut.kumajaya said:
Additional kernel modules for stock JB P31xx (tested) and P51xx (untested), contains:
- usb_wwan, ppp_async, and option module for PPP Widget
- dns_resolver, md4, and cifs module for cifs/samba filesystem support
- sunrpc, lockd, and nfs module for nfs filesystem support
Kernel config file attached.
Click to expand...
Click to collapse
Hi ketut.kumajaya,
I'm trying to use cifs.ko but i get:
/system/lib/modules # insmod cifs.ko
insmod: can't insert 'cifs.ko': unknown symbol in module or invalid parameter
I have:
/system/lib/modules # uname -a
Linux localhost 3.0.31-1084989 #1 SMP PREEMPT Mon Mar 25 14:53:07 KST 2013 armv7l GNU/Linux
I tried other cirs.ko with same result.
Can you give me some clues of what can I do?
Thank you.

Try insmod in order:
insmod dns_resolver.ko
insmod md4.ko
insmod cifs.ko
If something goes wrong, see the kernel messages using dmesg.

ketut.kumajaya said:
Try insmod in order:
insmod dns_resolver.ko
insmod md4.ko
insmod cifs.ko
If something goes wrong, see the kernel messages using dmesg.
Click to expand...
Click to collapse
Great!!!
That's the solution.
In my Tab 10.1 4.0.4 I'm loading (different kernel and different modules, of course):
insmod cifs.ko
insmod md4.ko
insmod nls_utf8.ko
So I was not thinking I should use a different order.
Thank you.

[KERNEL][L][STOCK][5.1.1]intersectRaven's Kernel - 20151018_20XX

Development Goals:
- stability
- energy savings due to more efficient ARM algorithms
- strictly no overclocking unless approved by the manufacturer or my source base integrates it (also, even if my source base integrates it, expect no support for it)
- no undervolting as well unless the manufacturer approves it since it's relatively pointless IMHO...
- all improvements should require MINIMAL user interaction (e.g. you don't need to do anything except flash the kernel or at the very least use SetCPU or the like to set fixed options)
- stability
*note: FAQ is at the 3rd post
20151018_20XX:
- some ramdisk cleanups for single image
- enabled KSM and ZRAM swapping for increased memory flexibility
20151015_15XX:
- added in partial resume support for *hopefully* better battery life
- tweak cubic algorithm just in case it's needed
20151003_20XX:
- added F2FS support (refer to 3rd post for MANUAL instructions on how to convert a partition to F2FS)
20151001_10XX:
- uploaded to personal site with updated compiler
20150922_16XX:
- tons of commits to improve power efficiency...just go to my GitHub...
20150831_19XX:
- added FIOPS IO scheduler and set it as default
- set FS options NOATIME and NODIRATIME always
- use 4k kernel stacks to save memory
20150815_18XX:
- first release for "back-to-basics" kernel
- turned off a ton of debugging options to improve performance
20150726_17XX:
- upgraded compiler
20150723_00XX:
- fixed bootloop while charging
20150702_23XX:
- modified ramdisk to support wifi properly on v2 of LeeDroid's Urbane port
20150623_22XX:
- more backports for improved efficiency
- changed kernel compression to XZ to make it even smaller
- limited maximum CPU frequency to 1Ghz to lower power consumption for multi version since mpdecision keeps on using max frequency too much
20150621_21XX:
- additional IPI reduction commits
- changed kernel compression to LZMA to make it smaller
20150620_17XX:
- reverted partial resume studies (seems to cause slowdowns somewhere but might also cause slightly more battery consumption)
- comment some printouts which are annoying
- kernel IPI improvements
20150617_23XX:
- minor improvements to reduce CPU load
- WiFi tweak
- rendering optimizations
20150612_08XX:
- added new feature for users of Urbane ROM which *might* also fix the bootup problem
20150611_09XX:
- added new image, wifi.multi.boot.img, which is multicore and with built-in wifi support so no need to flash Tasssadar's MOD when you upgrade the kernel (from an already modded ROM or from Urbane port)
***IF YOUR ROM IS NOT YET MODDED, DON'T USE THE WIFI.MULTI RELEASE SINCE IT MIGHT CAUSE AN ERROR WHEN YOU RUN TASSSADAR'S UPDATE ZIP***
20150607_09XX:
- back to usual local version tag
- rebased to newly released 5.1.1 Lenok branch on AOSP with some additions from Bass branch for WiFi throughput and energy saving
20150602_23XX:
- compiled using GCC 5.1
- special local version tag
20150602_08XX:
- modified panel to disable partial update since it seems to cause problems with current code (i.e. it disabled burn-in protection)
- special local version tag
20150531_18XX:
- removed a useless setting in the ramdisk which might cause increased CPU utilization thus less battery life
20150531_15XX:
- just added a new flashable image, multi-core for those who want...strictly for testing for now...I won't be responsible if your device explodes or burns off your wrist or something...
20150531_08XX:
- modified configuration with changes in Bass
- imported clock change for WiFi from Bass
20150530_08XX:
- has WiFi driver built-in waiting for ROM builders or modders to take advantage of
*we have WiFi here!
- first release for 5.1.1 based on Bass (Urbane) kernel source that was just released
20150503_16XX:
- rolled back previous changed as it increased battery consumption
20150423_23XX:
- ported one of my Kindle Fire modification which I just remembered could impact performance extremely well
- still has SELinux enabled as stock ROM doesn't play well with it disabled
20150412_21XX:
- numerous backports from linux 4.0 for timer, scheduler and ARM
20150411_21XX:
- numerous backports from linux 4.0 for timer, mutex and slub functionality performance improvements
20150411_19XX:
- tweaked kernel settings according to imoseyon's findings
20150410_18XX:
- timer optimization
20150409_00XX:
- merged Motorola's lowmemorykiller tree modification
- merged latest modifications to ondemand governor
20150402_07XX:
- uses updated Linaro toolchain
- integrated 5.0.2 changes in the kernel level (previous change was on the ramdisk level)
- some performance improvement commits
20150220_23XX:
- integrated changes for 5.0.2
*since changes were minimal, this might still work for 5.0.1...do that at your own risk though...
20150129_22XX:
- cherry-picked a patch for fixing the randomly occuring kernel BUG OOPS in smp_send_reschedule
20150127_22XX:
- fully tickless kernel
- adjust compiler tweaks even further
- reduce panel power consumption
20150117_18XX:
- updated my compiler with 15.01 Linaro gcc release source
- tweaked more compiler flags for maximum performance
20150112_22XX:
- first release with 2 kernels for single and dual core by default setup
- first release using my own compiler
- additional compiler flag optimizations
- merged NVidia power efficiency patches together with a scheduler optimization
20150103_18XX:
- enabled 2 cores and set to ondemand with maximum frequency limited to 800Mhz
- added several improvements from arter97's G Watch repo namely ARM instruction conversion to bx from mov pc, definition of L1 and L2 cache size for better compiler instruction generation and binder mutex change to real time for surfaceflinger improvement (in layman's term: graphics rendering improvement)
20141221_18XX:
- use compile time constants when possible for jiffies conversion
- several BT and i2c voltage tweaks to lower power consumption
20141217_00XX:
- same features as before only for Lollipop
20141206_07XX:
- enabled partial frame updates to hopefully improve screen power consumption
*not sure though since it might actually need ROM backing to work
20141203_17XX:
- added some filesystem optimizations
- compiled using Linaro 4.9.3
20141130_14XX:
- initial public release
- uses Linaro 4.9.2 for compilation
- enable use of UDIV/SDIV ARM instructions
- build-in byte-swap function
- memutils optimizations
- memcopy and string libraries now use glibc implementations
- optimized copy_page functions for ARM
Disclaimer:
Flash at your own risk.
You can find my other kernels at:
http://intersectraven.net/kernels
GitHub is at:
XDA:DevDB Information
intersectRaven's G Watch R Kernel, Kernel for the LG G Watch R
Contributors
intersectRaven
Kernel Special Features:
Version Information
Status: Stable
Created 2015-02-22
Last Updated 2015-02-22

Special Thanks To:
DooMLoRD - some patches I integrated are from his repo
faux123 - some patches I integrated are from his repo
arter97 - some patches I integrated are from his repo
imoseyon - kernel tweaks
lion567 - F2FS enabled TWRP recovery in 3rd post
Other devs I neglected to mention.

FAQ:
1.) How do I flash this on my device?
Use the "fastboot flash boot" command since I don't really have the time to support creation of a recovery flashable file. Optionally, you could also use the "fastboot boot" command to use the boot image temporarily which will reset to stock after a restart.
*also, this device does not have a custom recovery *YET* as of the time of this thread's creation
2.) How do I return to stock kernel?
Use the "fastboot flash boot" command using the stock boot image I provided in another thread here.
3.) Will you be releasing frequent updates?
Right now I don't see anything else needed to improve this kernel as I am quite satisfied with it. You could post suggestions BUT they must have MINIMAL USER INTERACTION or will only seek to enable editing of certain values.
4.) How do you verify that it flashed correctly?
Well, if it booted after fastboot showed the "writing" dialog, then it should be ok already. If you're ultra paranoid that maybe fastboot is lying to you or the NSA doesn't want you to know that it didn't overwrite the stock kernel which contains their secret spy stuff that wants to know how frequently you exercise you could enter the ff. command through adb:
cat /proc/version
and the kernel should show #7 and intersectRaven there together with the date that the kernel was compiled which is what I use to indicate the release.
5.) I see two files at the link above. What should I flash?
In the site you'll see single.boot.img, dual.boot.img, multi.boot.img and wifi.multi.boot.img. This indicates how many cores are enabled by default upon boot and if it's wifi ROM ready. If you're a heavy user, you might want to go with dual.boot.img so that you have 2 cores available or maybe multi.boot.img so that it'll adjust to at most 4 cores WHEN NEEDED. If you just use your watch for notifications and want maximum power savings, use single.boot.img.
6.) What about the wifi.multi.boot.img?
This is mainly for an ALREADY MODDED ROM (by Tasssadar) OR the URBANE ROM. With this, when you flash you won't need to rerun the update.zip provided by Tasssadar. Again, ONLY RUN THIS ON AN ALREADY MODDED ROM. If you flash this then run Tasssadar's Mod, you WILL encounter errors.
6.) If I flash the single boot image am I stuck forever with just one core being enabled?
No. If your watch is rooted, you can enable a core (even all 4 if you wish) through adb. The boot images are merely separated for bootup default convenience.
7.) How do you enable WiFi?
Go here.
8.) How do you convert a partition to F2FS?
a.) Download the mkfs.f2fs file here.
b.) Download a custom recovery somewhere and boot it.
c.) Push mkfs.f2fs somewhere. (tested on /sbin directory)
adb push mkfs.f2fs /sbin/
d.) In adb, issue a mount command to find the partition you wish to format.
*note, you can only format cache and userdata partitions and IF you choose to format the userdata, that's equivalent to a factory reset
adb -> mount
e.) Issue the ff. command replacing the X part with the partition you wish to format:
mkfs.f2fs -l X
e.g. mkfs.f2fs -l cache /dev/block/mmcblk0p20
f.) Reboot.
OR use this modified TWRP by lion567!

Reserved 3

I see you disabled secure booting, any idea how to get this device rooted? I made a kernel myself and disabled secure booting but I can't seem to figure out the root shell part, I pushed su to /data/local/tmp and set permissions but I still cant move it to system/bin..... frustrating

tonu42 said:
I see you disabled secure booting, any idea how to get this device rooted? I made a kernel myself and disabled secure booting but I can't seem to figure out the root shell part, I pushed su to /data/local/tmp and set permissions but I still cant move it to system/bin..... frustrating
Click to expand...
Click to collapse
I didn't disable secure boot I only replaced the kernel with my own. The ramdisk is exactly the same with stock. As for rooting, it's a bit tricky now due to SELinux being enabled. You could try disabling SELinux but that isn't really recommended. Also, I don't think modifying the system partition is good practice. You could just put it in the ramdisk so that it's recognized immediately as being "inside". I'll try and look into it further when I have time. I'm still looking at the battery consumption of my latest kernel for a few days so I can't modify until then.

What do you mean by putting it in the ramdisk so its "inside"? I tried to do something like that with rootsh but it didn't work. Also when I unmkbootimg'ed your kernel it had stuff from dory, isn't dory the regular lg g watch? We are lenok? I know a lot of the stuff is the same, the main goal I want to do is root so I can increase the vibration motor, but if I can't accomplish root easily I will be forced to make my own custom system.img with the modified values...... that would be a pain to be able to share it.

tonu42 said:
What do you mean by putting it in the ramdisk so its "inside"? I tried to do something like that with rootsh but it didn't work. Also when I unmkbootimg'ed your kernel it had stuff from dory, isn't dory the regular lg g watch? We are lenok? I know a lot of the stuff is the same, the main goal I want to do is root so I can increase the vibration motor, but if I can't accomplish root easily I will be forced to make my own custom system.img with the modified values...... that would be a pain to be able to share it.
Click to expand...
Click to collapse
Are you pertaining to the ramdisk or the kernel? I double-checked the ramdisk and there isn't any dory in there. As for the kernel, I used the lenok_defconfig so I don't really know if there is dory in there as well although they are derivatives so might be. I read your post in the other thread and it doesn't really need root to modify. You just need to give the user permission to those parameters so it can be changed through adb.

intersectRaven said:
Are you pertaining to the ramdisk or the kernel? I double-checked the ramdisk and there isn't any dory in there. As for the kernel, I used the lenok_defconfig so I don't really know if there is dory in there as well although they are derivatives so might be. I read your post in the other thread and it doesn't really need root to modify. You just need to give the user permission to those parameters so it can be changed through adb.
Click to expand...
Click to collapse
If only I knew how . Do I gotta edit init.d?

intersectRaven said:
. As for rooting, it's a bit tricky now due to SELinux being enabled.
Click to expand...
Click to collapse
so... we dont have root never? :S
i ll flash ur kernel, thanks!

tonu42 said:
If only I knew how . Do I gotta edit init.d?
Click to expand...
Click to collapse
I think the last time I did that I edited something in ueventd or something and not init.d although you could do that also. I'll have to check on what's the current best practice as I don't really like editing the ramdisk too much.
9ain said:
so... we dont have root never? :S
i ll flash ur kernel, thanks!
Click to expand...
Click to collapse
We'll have root eventually as more devs get the R but as of this time, no root yet!
*Personally, I don't get the point of rooting the watch as it's got huge limitations (battery, screen, controls, etc.) that I don't see the point...but that's me...

intersectRaven said:
I think the last time I did that I edited something in ueventd or something and not init.d although you could do that also. I'll have to check on what's the current best practice as I don't really like editing the ramdisk too much.
We'll have root eventually as more devs get the R but as of this time, no root yet!
*Personally, I don't get the point of rooting the watch as it's got huge limitations (battery, screen, controls, etc.) that I don't see the point...but that's me...
Click to expand...
Click to collapse
i want to change dpi

I want to change the vibration strength and duration!
Gesendet von meinem SM-N9005 mit Tapatalk

cybermungo said:
I want to change the vibration strength and duration!
Gesendet von meinem SM-N9005 mit Tapatalk
Click to expand...
Click to collapse
its the same thing xD

9ain said:
its the same thing xD
Click to expand...
Click to collapse
Ah ok...
Gesendet von meinem SM-N9005 mit Tapatalk

cybermungo said:
Ah ok...
Gesendet von meinem SM-N9005 mit Tapatalk
Click to expand...
Click to collapse
No its not, strength and duration are two totally different setting files and methods in the kernel driver. It also has braking_ms which is the gap you notice in between vibrations.

tonu42 said:
No its not, strength and duration are two totally different setting files and methods in the kernel driver. It also has braking_ms which is the gap you notice in between vibrations.
Click to expand...
Click to collapse
The duration is what causes the motor to accelerate more and be more strength.... more duration=more strength (Until maximum possible).
/sys/class/timed_output/vibrator/amp
/sys/class/timed_output/vibrator/driving_ms
this is the files to change (we need root)

9ain said:
The duration is what causes the motor to accelerate more and be more strength.... more duration=more strength (Until maximum possible).
/sys/class/timed_output/vibrator/amp
/sys/class/timed_output/vibrator/driving_ms
this is the files to change (we need root)
Click to expand...
Click to collapse
You listed two files. Go look in the kernel and look at the driver. Amp is related to the gain and the gain is in mV i believe. Of course increasing the duration will also make it feel stronger so increasing both helps.

9ain said:
The duration is what causes the motor to accelerate more and be more strength.... more duration=more strength (Until maximum possible).
/sys/class/timed_output/vibrator/amp
/sys/class/timed_output/vibrator/driving_ms
this is the files to change (we need root)
Click to expand...
Click to collapse
I looked at doing this but it seems SELinux is going crazy and not recognizing attempts to override the sysfs protection so we either really need root, disable SELinux altogether (don't like), or set it in the kernel (no user override which I don't think people like).
tonu42 said:
You listed two files. Go look in the kernel and look at the driver. Amp is related to the gain and the gain is in mV i believe. Of course increasing the duration will also make it feel stronger so increasing both helps.
Click to expand...
Click to collapse
Yep it's in mV with a range of 0 - 100.

My ADB cant find the watch. My thought is that it is because computer cant find drivers to the watch when I connect it. Where can I find usb-drivers for my watch?

[KERNEL][L][STOCK][5.1]intersectRaven's Kernel - 20150524_05XX

Development Goals:
- stability
- energy savings due to more efficient ARM algorithms
- strictly no overclocking unless approved by the manufacturer or my source base integrates it (also, even if my source base integrates it, expect no support for it)
- no undervolting as well unless the manufacturer approves it since it's relatively pointless IMHO...
- all improvements should require MINIMAL user interaction (e.g. you don't need to do anything except flash the kernel or at the very least use SetCPU or the like to set fixed options)
- stability
*note: FAQ is at the 3rd post
Latest Kernel Here
Boot-B -> LBY29G
Boot-O -> LMY47O PH
Boot-M -> LMY47O India
OR
Boot-Universal -> custom recovery flashable zip for all ROMs (I hope :fingers-crossed
*there are significant ramdisk differences between PH and India versions which is weird
20150524_05XX:
- missed something in the previous commit
*this is why I don't like developing kernels on devices I don't use or stopped using actively :/
20150523_21XX:
- implemented minor config changes and a better fix for kernel ooops upon changing CPU governors
20150509_11XX:
- modified proportional frequency allocation algorithm to prefer minimum frequency more
20150503_17XX:
- improved power efficiency of entire kernel
20150426_09XX:
- optimized frequency scaling algorithm to minimize scaling to max during hotplug and under certain situations
20150423_22XX:
- ported one of my Kindle Fire modification which I just remembered could impact performance extremely well
20150417_14XX:
- reverted RCU patch mistakenly committed without dependency which caused RCU slowdown
20150412_20XX:
- numerous backports from linux 4.0 for timer, scheduler and ARM
20150411_21XX:
- numerous backports from linux 4.0 for timer, mutex and slub functionality performance improvements
20150411_18XX:
- kernel tweaks from imoseyon
20150410_17XX:
- timer optimization
20150409_17XX:
- disabled dithering since I think hardware doesn't need it (please report any sign of image degradation)
- now also in flashable zip form (please test as I don't have custom recovery)
20150408_23XX:
- merged Motorola's lowmemorykiller tree improvement
- applied latest ondemand patches to hotplug to improve frequency selection
20150407_14XX:
- recoded some MediaTek modifications with more optimal instructions
- removed more unnecessary kernel options
20150405_19XX:
- removed touch boost as it seems to be unnecessary
- removed some useless logging entries
- adjusted some code that prevented the frequency from being ramped down immediately
20150405_10XX:
- changed default IO scheduler to ROW imported from Lenok source with additional commits due to MediaTek changes
- modified readahead value to 512KB
20150403_16XX:
- bug fix due to incorrect scoping of the touch frequency modification causing excessive use of 747Mhz
20150402_06XX:
- integrated Mali commits by varun
- some minor optimizations
20150331_22XX:
- modified hotplug governor to use ondemand algorithm
- hotplugging now doesn't raise frequency to max before doing a hotplug operation
- touch boost frequency now set to 747Mhz instead of max to lower power consumption
20150329_16XX:
- finished porting all relevant commits from Lenok source to Sprout
- initial full release
- significant changes include:
enabling of full tickless mode
modification of some kernel libraries to use optimized ARM instructions
Disclaimer:
Flash at your own risk.
You can find my other kernels at:
http://intersectraven.euroskank.com/kernels
GitHub is at:
intersectRaven's GitHub
XDA:DevDB Information
intersectRaven's Android One Kernel, Kernel for the OEM Cross Device Development
Contributors
intersectRaven
Kernel Special Features:
Version Information
Status: Testing
Created 2015-04-03
Last Updated 2015-04-02

Special Thanks To:
DooMLoRD - some patches I integrated are from his repo
faux123 - some patches I integrated are from his repo
arter97 - some patches I integrated are from his repo
varun - Mali patches are from his repo and his generic kernel implementation
Other devs I neglected to mention.

FAQ:
1.) How do I flash this on my device?
You could use fastboot, flashify, or flash through recovery using the provided recovery flashable zips.
2.) How do I return to stock kernel?
Use the "fastboot flash boot" command using the stock boot image I provided in another thread here.
3.) Will you be releasing frequent updates?
Right now I don't see anything else needed to improve this kernel as I am quite satisfied with it. You could post suggestions BUT they must have MINIMAL USER INTERACTION or will only seek to enable editing of certain values.
4.) How do you verify that it flashed correctly?
Well, if it booted after fastboot showed the "writing" dialog, then it should be ok already. If you're ultra paranoid that maybe fastboot is lying to you or the NSA doesn't want you to know that it didn't overwrite the stock kernel which contains their secret spy stuff that wants to know how frequently you exercise you could enter the ff. command through adb:
cat /proc/version
and the kernel should show #7 and intersectRaven there together with the date that the kernel was compiled which is what I use to indicate the release.

Reserved 3

which is better thunderzap or yours? thanks

Androidoo said:
which is better thunderzap or yours? thanks
Click to expand...
Click to collapse
I guess it's not right to compare both kernel. Both are awesome, but this kernel are optimized for stock, while ThunderZap are optimized for both CM12.1 and stock.

Will this improve battery life
Sent from my Android One using XDA Free mobile app

Kohul Raj said:
Will this improve battery life
Sent from my Android One using XDA Free mobile app
Click to expand...
Click to collapse
Yes, depends on your usage. I notice a bit of increase in battery life, but that's all depends on your usage.

F4uzan said:
Yes, depends on your usage. I notice a bit of increase in battery life, but that's all depends on your usage.
Click to expand...
Click to collapse
Interesting. What version are you using currently? 20150402_06XX? Can you use the one after that (or the latest one released today) and observe battery life with your typical usage? Might be the bug I introduced due to an improper understanding of what a line was doing.

intersectRaven said:
Interesting. What version are you using currently? 20150402_06XX? Can you use the one after that (or the latest one released today) and observe battery life with your typical usage? Might be the bug I introduced due to an improper understanding of what a line was doing.
Click to expand...
Click to collapse
Sure, I'll try Gotta backup and reflash stock then.
-EDIT : I have flashed it, I'll test it for two days and I'll report the results

F4uzan said:
Sure, I'll try Gotta backup and reflash stock then.
-EDIT : I have flashed it, I'll test it for two days and I'll report the results
Click to expand...
Click to collapse
Thanks! You didn't have to if you're not on stock already so I appreciate it!

I'm happy because android one development is growing now
By the way, i'm in thunderzap kernel, can i flash this directly? or i have to go back to stock kernel then flash this? Thanks..

yonzz said:
I'm happy because android one development is growing now
By the way, i'm in thunderzap kernel, can i flash this directly? or i have to go back to stock kernel then flash this? Thanks..
Click to expand...
Click to collapse
This is for stock ROMs. Doesn't matter if you're using a different kernel, what's important is you're not on CM or any non-AOSP based ROM.

anyone can report the result please ? ?
Sent from my MITO_A10 using xda Forum

mrahmanda said:
anyone can report the result please ?
Sent from my MITO_A10 using xda Forum
Click to expand...
Click to collapse
I have used it for a day, there is a slight improvement in battery life.

Can you add USB OTG support and double tap to wake

stuck after android logo... using O for LBY ... build number LBY25G

acus123 said:
stuck after android logo... using O for LBY ... build number LBY25G
Click to expand...
Click to collapse
That's odd. Did you flash anything else before or is this pure stock Cherry Mobile One?

Way better than stock kernel. Performance has improved and battery drains slowly(Compared to stock kernel). I would prefer this kernel over stock anytime!
Regards.
PS: I would request the developer to make a flashable ZIP next time or can provide as an additional package because it's a bit inconvenient to open up PC and flash via ADB. Anyway, a great work!

I've tested the kernel extensively over few days and I can confirm battery improvements

[WIP][6.0][CM13] Custom 3.0 kernel with lowmemorykiller optimizations

TLDR: in Oct 2016, the patch has been merged into official Cyanogenmod / Lineage kernel sources: https://github.com/LineageOS/androi...mmit/0e899ff2828df771b524dc52f19f29c0c5cd5842
-------------------------------------------------------------------------
There has been much discussion on UI freezes / lags with CM13 on the Droid 4 in another thread which turned out to be related to some quarrel between Android lowmemorykiller (LMK), ZRAM and kswapd direct reclaim...
As a workaround, increasing extra_free_kbytes (to 75000 in my case) turned out to reduce lags a great deal. (This can be done e.g. with Kernel Adiutor Mod)
Now, I made a small kernel patch adapted from 3.4 kernel which makes LMK account for swap memory, i.e. LMK does only consider memory pages as free which won't require swapping:
Code:
diff --git a/drivers/staging/android/lowmemorykiller.c b/drivers/staging/android/lowmemorykiller.c
index 86d5195..d4e4513 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -34,6 +34,7 @@
#include <linux/mm.h>
#include <linux/oom.h>
#include <linux/sched.h>
+#include <linux/swap.h>
#include <linux/notifier.h>
static uint32_t lowmem_debug_level = 2;
@@ -90,7 +91,7 @@ static int lowmem_shrink(struct shrinker *s, struct shrink_control *sc)
int selected_tasksize = 0;
int selected_oom_adj;
int array_size = ARRAY_SIZE(lowmem_adj);
- int other_free = global_page_state(NR_FREE_PAGES);
+ int other_free = global_page_state(NR_FREE_PAGES) - totalreserve_pages;
int other_file = global_page_state(NR_FILE_PAGES) -
global_page_state(NR_SHMEM);
If you want to try, just flash the following zip file via safestrap recovery over existing CM13 (both - kernel and ramdisk.img - are included): cm13_lmkpatch_v1.zip
I am not sure yet, if extra_free_kbytes can be reduced now (seemingly not, I'm still at 75000), nor if LMK watermarks can be lowered (maybe yes, I have set it to Kernel Adiutor's Agressive Profile)....
....but I'm very much interested in your findings!
If this turns out to be an improvement, I'll commit a change request to review.cyanogenmod.org

Seems that I was wrong with extra_free_kbytes and LMK watermarks for the patched kernel...
...just leave extra_free_kbytes at stock settings in the first place and maybe try Kernel Adiutor aggressive profile for LMK with empty app watermark increased to 256MB.
Also, I have another gem for you: 3.0 kernel with LMK optimizations adapted from https://github.com/XperiaSTE/android_kernel_sony_u8500/ and https://gitlab.com/k2wl/g2_kernel/
Download:
cm13_lmkpatch_v2.zip (first try)
cm13_lmkpatch_v2.1.zip (added some fixes from https://gitlab.com/k2wl/g2_kernel/commits/kitkat-mr1-rel-razrm)
...this one runs even smoother!
I have extra_free_kbytes = 16000 and LMK watermarks @ Kernel Adiutor aggressive profile and there is plenty of free RAM (around 200MB) and the phone seems to have much less trouble with running several heavy apps in parallel!

Thanks. Great job! The phone's much more responsive now, almost as on stock JB. But could this patch be integrated with Swap SDCard and undervolt mods?

rabinhood said:
Thanks. Great job! The phone's much more responsive now, almost as on stock JB. But could this patch be integrated with Swap SDCard and undervolt mods?
Click to expand...
Click to collapse
...of course. Just wait a couple of days to give us some more time for testing and optimization, I will then commit the patch to official Cyanogenmod and @joojoobee666 will integrate it into his UV kernel.
I'd also like to have more feedback from other users.
My current configuration with cm13_lmkpatch_v2.1 is:
- extra_free_kbytes = 32000 (keeping more free RAM for ZRAM decompression)
- LMK watermarks: Kernel Aduitor medium with empty app = 160MB.

Thanks. I just set 'aggresive' profile and extra_free_kbytes=16000, as you suggested before, but I'll try other settings too.
[edit]
I've found that with your patch, D4 is much, much smoother, even without Kernel Adiutor tweaks.

u.b.o.o.t said:
...of course. Just wait a couple of days to give us some more time for testing and optimization, I will then commit the patch to official Cyanogenmod and @joojoobee666 will integrate it into his UV kernel.
I'd also like to have more feedback from other users.
My current configuration with cm13_lmkpatch_v2.1 is:
- extra_free_kbytes = 32000 (keeping more free RAM for ZRAM decompression)
- LMK watermarks: Kernel Aduitor medium with empty app = 160MB.
Click to expand...
Click to collapse
Hi,
Your custom kernel and ramdisk caused my RAZR to boot endlessly. I tried the custom kernel with the default ramdisk, and the default kernel with the custom ramdisk. Both didn't work.

Bobcus Leper said:
Your custom kernel and ramdisk caused my RAZR to boot endlessly. I tried the custom kernel with the default ramdisk, and the default kernel with the custom ramdisk. Both didn't work.
Click to expand...
Click to collapse
Sorry for that but.... my kernel is for the Droid 4, only... I don't know anything about the RAZR... same hardware / device tree?
Seems that @joojoobee666 has included some magic into his builds which make it work for RAZR and Droid4 simultaneously...
But wait - in a couple of days, there should be a RAZR kernel with lmk optimizations for you to play with: http://forum.xda-developers.com/showpost.php?p=68904722&postcount=221

Hi folks,
I created a new kernel with some further optimizations.
...credits go to Motorola people at https://gitlab.com/k2wl/g2_kernel
In particular, I merged the following patches:
https://gitlab.com/k2wl/g2_kernel/commit/22d990a58fc17b3f0155e15eb2dc3efa037bea1c
https://gitlab.com/k2wl/g2_kernel/commit/7093310c60c972387b5a375ac3b407e2b04f591e
https://gitlab.com/k2wl/g2_kernel/commit/04c5d59093fa8148e9caf48c5c8b8a3f7a4db159
https://gitlab.com/k2wl/g2_kernel/commit/39eaf73c50d34287ef3c79a2b00d977655c1ceeb
https://gitlab.com/k2wl/g2_kernel/commit/dabca8deb03554f8da8d4f88774b02f004ad99c7
I also incorporated a small change from Wiko Sunny kernel which includes swapped pages when calculating the memory currently used by a process.
Download (Droid 4 only!): cm13_lmkpatch_v2.2.zip
Now, we need some further testing and I'd like to have your feedback regarding which values for extra_free_kbytes and LMK watermarks are optimal for you.

Thanks. Now I wanted to ask one, maybe silly, question. I've just installed your v2.2 mod, but since I'm really in need of traditional/normal sdcard access, I flashed SDCard-swap mod afterwards. So right now I'm using 'kernel' file from your mod, and 'ramdisk.img' from the other. Everything seems normal, and I have a feeling my D4 runs smoother than without your mod. Is it enough to flash only 'kernel' file to improve lags, or do I have some speed delusions caused by placebo effect?

The ramdisk contains kernel modules which must match the kernel. For some time I was working on a patch that also touches some core functionality of the kernel. In such a case, kernel modules & ramdisk is affected too. But I did not include these changes yet.
Hence, there should not be any incompatibility between my kernel and official CM13.0 ramdisk at the moment.

u.b.o.o.t said:
- LMK watermarks: Kernel Aduitor medium with empty app = 160MB.
Click to expand...
Click to collapse
Works really well with 2.2, thank you for this! Even without changing anything in Adiutor, the phone already responds a lot better than before. :victory:
I didn't touch extra_free_kbytes, though. Increasing it to 32000 makes starting up apps considerably slower. The default of 6075 is fine for me.

You're right - with latest patch, increasing extra_free_kbytes does not seem to be necessary anymore.
Also, lowering LMK watermarks seems reasonible now, which allows more apps to stay in memory. I'm currently using medium profile with empty app at 128MB.

what da hellllll
y dis fone so fast now? lol
good job, uboot.
gonna put it through its paces tomorrow during work hours.
<3

I folks!
There are now 2 versions of my patch which I'd like to evaluate / get feedback from you:
1.) ANDROID_LMK_PARAM_AUTO_TUNE enabled. This is the one you already know: cm13_lmkpatch_v2.2.zip It contains (among others) the following changes by Motorola people:
https://gitlab.com/k2wl/g2_kernel/commit/22d990a58fc17b3f0155e15eb2dc3efa037bea1c
https://gitlab.com/k2wl/g2_kernel/commit/7093310c60c972387b5a375ac3b407e2b04f591e
2.) ANDROID_LMK_PARAM_AUTO_TUNE disabled. This is what I commited to Cyanogenmod code review and what has just been integrated by @joojoobee666 into his OC kernel. It is closer to Google's official kernel sources. Droid4 owners may as well flash this one, which is based on official cm-13.0: cm13_lmkpatch_v2.3.zip

@u.b.o.o.t
I just flashed new kernel by joojoobee666. Think that overall performance is better but big apps are still causing troubles. Browser, settings etc seems to be opening faster. Good job! :good:
Currently I'm using these settings: LMK medium profile with empty app at 128MB and and extra_free_kbytes=16000.
I guess that newest kernels by joojoobee666 has cm13_lmkpatch_v2.3.zip built in?

Flash-A-Holic said:
@u.b.o.o.t
I just flashed new kernel by joojoobee666. Think that overall performance is better but big apps are still causing troubles. Browser, settings etc seems to be opening faster. Good job! :good:
Click to expand...
Click to collapse
better than cm13_lmkpatch_v2.2.zip or better than previous OC kernel?
Flash-A-Holic said:
Currently I'm using these settings: LMK medium profile with empty app at 128MB and and extra_free_kbytes=16000.
I guess that newest kernels by joojoobee666 has cm13_lmkpatch_v2.3.zip built in?
Click to expand...
Click to collapse
Yes, exactly.
Yesterday I had some annoying lags with incoming call with lmkpatch_v2.3, empty app watermark at 128MB and extra_free_kbytes=8000. Increasing to 16000 seemed to help a bit, but I'm now back at v2.2 with lmk auto tuning enabled.
I will keep that now for a couple of days of testing...
PS: with stock lmk watermarks, there should be less trouble, but more app killing, and what I'm trying here is to find the sweet spot between maximum performance and minimum lmk kills / app restarts.

u.b.o.o.t said:
better than cm13_lmkpatch_v2.2.zip or better than previous OC kernel?
Click to expand...
Click to collapse
Better than previous OC kernel with Kernel Adiutor tweaks (extra_free_kbytes 75000, LMK agressive profile).

Does anyone of you guys have increased battery drain with one of my lmk patches?
I'm facing SUSPEND_BACKOFF kernel wakelocks (https://github.com/asksven/BetterBatteryStats-Knowledge-Base/wiki/suspend_backoff) preventing the device from going deep asleep and it seems this occures as soon as Wifi has been switched on and off...
EDIT: it's not my patches' fault... having the same issues with standard cm13 kernel...

Do you have any guesses what kernel parameters provide the smoothest operation? I'm using aggresive LMK policy, min free kbytes and extra free kbytes 10000, and Z-RAM 200 MB. Definitely my phone's smoother than only with Your latest patch, but that's only my feeling. Do you know any objective means to measure performance gain? Maybe some benchmarks? Considering battery use, I found no striking changes. I believe stock JB kernel was better in terms of energy use, but IMHO the difference is only slighty visible.

I'm still evaluating but at the moment I'm most confident with 2.2 patch with min_free_kbytes, extra_free_kbytes, and zram at stock settings and lmk profile = aggressive.
Patch 2.3 as well as @joojoobee666's current build have lmk autotuning disabled and seem to require extra_free_kbytes=16000...32000.
But I won't touch min_free_kbytes - there are too many implications / side effects.

[MODS DELETE THIS THREAD] exNoShadez-eas

Mod edit: Thread closed on owner's request!
exNoShadez-EAS Kernel
FEATURES
- Current LTS release -> Linux-3.18.114
- Energy Aware Scheduling
- Schedutil (default Cpu Governor)
- RCU infrastructure backport (with expert mode enabled)
- Cpu-Boost / Input Boosting (enabled by default)
- BINFMT_MISC support (NOT mounted on boot).
- Kernel Hardening/Protection (CopperheadOS/Grsec/Pax Marlin kernel hardening features)
- leds-qpnp: Notification LED control - V1.1c (Boeffla) - Adapted for Marlin
- Binder_rt = My own re-implementation of AOSP Binder that uses rt_mutexes; supporting priority inheritance
- Improved scheduling/determinism for high priority threads/tasks
- Backported Scheduling, Locking and Workqueue subsystem code from Newer Linux kernels.
- Audio Driver enhancements / backports (from Wahoo/Pixel 2)
- Sound/Audio driver Tweaks (bug fixes, scheduling improvements)
- forced Interrupt threading enabled
- Wifi Mac Address Randomization
- WireGuard VPN kernel module support (more info soon)
- KCal Advanced Colour control
- Improved ASLR (in kernel)
- USB Fast Charge
- Wake Gestures
- GCC 6/7+ Fixes
- Built with GCC-8.x-dev
- and more
Contains code from everywhere: Code Aurora, Flar2/Marlin, CopperheadOS, AOSP, Project-EAS, Freak7/Kirisakura, Linaro, Pixel 2 kernel sources, mainline linux and elsewhere. Modifications and backports by me, as well.
BACKGROUND
I wanted a kernel for My Pixel that had 'all of the things', it didn't exist... So I'm working on my own kernel. I try to balance Security/hardening, experimental features with high Performance and battery life. <- not an easy task! ... Some of the security features do come with overhead, but if you use apps that are CPU heavy / processing and/or require low latency - they will perform well (at the cost of chewing some battery life, of course).... Battery life and SOT are very reasonable though.
WARNING / VERY IMPORTANT: This kernel isn't compatible with installing TWRP ~> meaning; you must use the fastboot version of TWRP (used in RAM) , flash the kernel and NOT install TWRP to your system (the kernel is too big for TWRP to co-exist).... This may sound inconvenient, but there are a number of valid reasons to avoid reducing a kernel's size in order to support TWRP installation, in the boot partition.
***Fun facts on this subject below => in the 2nd post: PLEASE READ: to understand my motivation***
TWRP REMOVAL
*To remove TWRP from your system; You need the stock boot.img from your running/current firmware (which is inside of the factory image zips) or use the Nov Stock boot.img provided here. Then it's as simple as flashing the boot.img to wipe TWRP;
fastboot flash boot_a /path/to/boot.img
fastboot flash boot_b /path/to/boot.img
Stock 8.1 July 2018 Boot.img => https://github.com/nine7nine/Apps/raw/master/SailfishStockJulyBoot.img
Now you can proceed with using the TWRP fastboot boot.img to flash my kernel, magisk/supersu or whatever else....
Fastboot twrp boot image => https://dl.twrp.me/sailfish/twrp-3.2.2-0-sailfish.img
WARNING: This shouldn't need to be said, but we did have someone who did this, so I'm adding a sticky/warning here; do NOT EVER re-lock your bootloader after flashing any kind of custom software, kernels, etc to your device - *it will brick your phone*. Meaning you are screwed would need an RMA / replacement device ... everyone in the XDA community should know better, but still; worth mentioning....
IMPORTANT:
Before asking questions; Please read through the thread (starting with the last few pages) - I shouldn't need to be repeatedly answering the same questions over and over again. It's good practice to get into the habit of reading through threads before asking questions in any thread on XDA, as more often then not; you're question has probably been answered. Thanks!
EXNS-EAS KERNEL DOWNLOAD:
JULY 2018 OREO 8.1 RELEASE exNoShades-eas Kernel Flashable zip
https://github.com/nine7nine/Apps/raw/master/exNoShadez_eas_v2.8.2_f94351f.zip
It is stable, high performance and very responsive...
Important: You will need root; I don't support non-rooted devices && some features require it. I recommend using Magisk; https://forum.xda-developers.com/apps/magisk/beta-magisk-v13-0-0980cb6-t3618589 ...
NOTE: Make sure to flash the latest Magisk beta *before* flashing the kernel zip. ...
More Background / Important Notes:
Binder_RT:
My own port and re-implementation of the Binder Kernel Driver; a slightly modified version of The AOSP binder.
Binder_RT uses rt_mutexes as opposed to mutexes for locking in Binder, ion, ashmem, etc... rt_mutexes support priority inheritance and should improve determinism in Binder, speed up IPC, Ion and Ashmem => Allowing applications that require low-latency, tight deadlines, low jitter and deterministic behaviour to perform better ~ This re-implementation is proving to be the great for those types of applications. The goal here is to help ensure that the Kernel and Binder's high priority && time critical threads and tasks are properly prioritized... Example; audio buffers arriving on time / no buffer underruns... *Further development work is planned to research, experiment with and improve Binder_RT.
rt_mutex documentation, for those interested;
https://github.com/nine7nine/Marlin_exns-eas/blob/EXNS_EAS/Documentation/locking/rt-mutex.txt
https://github.com/nine7nine/Marlin_exns-eas/blob/EXNS_EAS/Documentation/locking/rt-mutex-design.txt
CPU-Boost / Input Boosting:
Touch inputs boost CPU frequencies (thus improves performance and responsiveness).
# Cpu-boot / Input boost settings
write /sys/module/cpu_boost/parameters/input_boost_enabled 1
write /sys/module/cpu_boost/parameters/input_boost_freq "0:1363200 1:0 2:1900800 3:0"
write /sys/module/cpu_boost/parameters/input_boost_ms 100
IO/ CPU Governors:
This kernel doesn't include a thousand io/cpu governors. IO-wise; CFQ is the default, but we've got a few in there. chose your poison, but know that the majority of my testing is centered around cfq and deadline. CPU Governor-wise the common Linux CPU governors are there; along with Sched and Schedutil....
Stick with Schedutil - on idle, it draws very little power and in most 'peak performance situations, it should do very well..... I'm getting great battery life, sot and performance.
Managing Kernel Settings:
Get EX Kernel Manager - my original code on github was forked from EX kernel, before rebasing it - but EXKM will give you access to 99% of my kernel's settings.
My 8.1 Kernel Sources: https://github.com/nine7nine/Marlin_exns-eas
Donations via PayPal very much appreciated. I do put a significant amount of energy and time into researching, development, testing / QA and also providing support/help to end-users... It's definitely not mandatory to donate; but If you appreciate the effort, see value or benefits from using my kernel on your device and can afford to; Use the "Donate to me" button or the below link... It makes a big difference. thanks!
https://www.paypal.me/jrdnjhnstn

Why TWRP Installations are NOT supported:
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
(and why I'm not using it!)
Most custom/android kernel devs are using the above configuration in kernel compilation, which is arguably very BAD... I understand that boot partitions are small and the desire to install TWRP to them, thus there is a need to reduce the kernel's size....and yes, this will achieve that - However;
1. SUSE, RedHat, etc (Enterprise linux) disable CONFIG_CC_OPTIMIZE_FOR_SIZE -> it's original use case has proven to be invalid. Even Google (in their own documentation) advise against using this; https://source.android.com/devices/tech/perf/boot-times ....
2. It suppresses useful compiler warnings....
3. As SOCs have become more powerful, google has come to the same conclusion that Enterprise Linux did back in 2012.
4. by turning off CONFIG_CC_OPTIMIZE_FOR_SIZE, we achieve better performance, boot time and better cache utilization.
Clark Williams / Redhat Bugzilla said:
* Cause: CONFIG_CC_OPTIMIZE_FOR_SIZE set with assumption that smaller code would yield hot cache lines and good performance
* Consequence: this config caused gcc to generate jump-to-jump code which causes cache line bouncing, hurting performance
* Fix: turn off CONFIG_CC_OPTIMIZE_FOR_SIZE
* Result:slightly larger kernel but better cache utilization
Click to expand...
Click to collapse
(The Above is quoted from Clark Williams, A Senior Software Architect @ RedHat -> https://bugzilla.redhat.com/show_bug.cgi?id=796297)
I know of no other way to significantly reduce kernel size. Disabling some debugging, unneeded features, etc helps - but not enough.... I am focusing on optimization, using newer builds of GCC/Linaro, performance enhancements, fixing compilation errors, etc, etc -> these things are more important than trying to support TWRP installation. Therefore; I do NOT support installing TWRP....

I like it so far, very good kernel.

Awesome! Always nice to have choices
I've seen you post around that you made x change to your own kernel, glad you finally made it public!
Does it have all of franco's wakelocks blocked by default?

グリッチ said:
Awesome! Always nice to have choices
I've seen you post around that you made x change to your own kernel, glad you finally made it public!
Does it have all of franco's wakelocks blocked by default?
Click to expand...
Click to collapse
hey, it includes franco's wakelocks stuff. I don't think all are blocked, I actually don't touch them in my init rc. ... but some are blocked by default, for sure. can be set by user...
yeah, I've got my kernel to a point now, where it is somewhat unique && is drawing in most of the best features from every custom kernel for the pixel (my opinion). very stable too, thus far. so makes sense to make it public.
it's got the RCU (read copy update) infrastructure from linux-4.9... a ton of core, sched, Walt, etc from linux-4.4+ (specifically, from EAS-Project / msm8998 OP5 - which was painful to backport. wish we didn't have a 3.18 kernel. lol) afaik, it's the only Marlin kernel with Dynamic Stune Boost and aside from CopperheadOS; the only marlin kernel with a subset of the PAX/grsec kernel security enhancements and the Mac randomization... also has all of the audio enhancements from the kernel ur running ?

siheals said:
I like it so far, very good kernel.
Click to expand...
Click to collapse
Hey! thanks for testing it out. let me know how things go, your impressions, etc.
I'll be updating this kernel constantly, so if u end up liking it; you can expect that it will always include security patches, linux LTS incremental patches, etc...
it's my daily driver, so i keep on top of it.

Superb! Thanks for clarifying.
I will give it a run when November update releases cuz I'm lazy >.< but am excited and looking forward to it ^_^

グリッチ said:
Superb! Thanks for clarifying.
I will give it a run when November update releases cuz I'm lazy >.< but am excited and looking forward to it ^_^
Click to expand...
Click to collapse
no probz. As soon as the november updates arrive, i will be adding whatever patches are needed... so expect that to be there...
i also pull from Code Aurora msm-3.18 for 8996, so my kernel gets updates to drivers, core, etc that google hasn't picked up yet.

Just Testing 3.18.79 + latest Code Aurura updates for today ....AND;
re-enabling a hardening feature that I thought was draining battery life (Likely not, was probably another removed patch - that isn't in the current release.)
I'll update the link later on and - on my github; where I link to for downloads; there will be older releases labeled - ie:
exNoShadez_eas.zip (current release / link) will become -> exNoShadez_eas_3.18.78_oct.zip,
when it is replaced by 3.18.79 + other updates / patchwork.... The current release will always be -> exNoShadez_eas.zip
UPDATE:
While I haven't updated exNoShadez_eas.zip link/version, * I have posted a zip with the above changes - I'll be testing it for a while before updating the link because it's hard to gauge battery life without a lot of testing / time spent.... So I would say, if anyone is eager - they can test it, but wait at least 12-24hours from testing the current available release - so you can actually make some sort of real-usage comparision.
link: https://github.com/nine7nine/Apps/raw/master/exNoShadez_eas_3.18.79_harden.zip

Glad to see you have posted this man. Setting up a pixel for my friend and as i was browsing the forums noticed you have a lot of good kernel work. Was literally about to PM you a few days ago for your kernel and then happened to see this post today. Can't wait to try it out!

Warrimonk said:
Glad to see you have posted this man. Setting up a pixel for my friend and as i was browsing the forums noticed you have a lot of good kernel work. Was literally about to PM you a few days ago for your kernel and then happened to see this post today. Can't wait to try it out!
Click to expand...
Click to collapse
All good, man.
It only makes sense that I would share my kernel, when I felt it was ready for that - just keep in mind, that for now - I have marked it as Beta / Testing, as it's pretty new (although, aside from the EAS code / Dynamic Stune Boost - the rest has been thoroughly vetted)....
So yeah, give it a run, let me know how things go! thanks

Unsure if I am doing something wrong or not, but when I try to flash your kernel I get an error stating : "New Image larger than boot partition. Aborting...."
EX Kernel flashed fine. Using TWRP 3.1.1-1

Warrimonk said:
Unsure if I am doing something wrong or not, but when I try to flash your kernel I get an error stating : "New Image larger than boot partition. Aborting...."
EX Kernel flashed fine. Using TWRP RC1.
Click to expand...
Click to collapse
Why aren't you using the newest stable version of TWRP?
RC1 = release candidate 1
afaik, latest release is 3.1.1-1 stable for the pixel.... https://dl.twrp.me/sailfish/
Using an old version might be your issue. Update, then try.

nine7nine said:
Why aren't you using the newest stable version of TWRP?
RC1 = release candidate 1
afaik, latest release is 3.1.1-1 stable for the pixel.... https://dl.twrp.me/sailfish/
Using an old version might be your issue. Update, then try.
Click to expand...
Click to collapse
Apparently I am using TWRP3.1.1-1 . The thread was called RC1 So I mistakenly assumes that was still the current version.

Warrimonk said:
Apparently I am using TWRP3.1.1-1 . The thread was called RC1 So I mistakenly assumes that was still the current version.
Click to expand...
Click to collapse
Can confirm this, I'm on 3.1.1-1 too and got this issue.
I'm running 8.0.0 (OPR3.170623.008, Oct 2017) build.

Keasby said:
Can confirm this, I'm on 3.1.1-1 too and got this issue.
I'm running 8.0.0 (OPR3.170623.008, Oct 2017) build.
Click to expand...
Click to collapse
kk. I'll look into this - I (obviously) do not have this problem..... What firmware images do you use?
I'm on Rogers/Canada, maybe the boot partition is a different size on some firmwares (?)....
I can also look at shrinking the boot.img, which could fix it. My boot.img is slightly bigger than the shipped boot.img and I do have an idea on how to shrink it a bit, you'll have to wait until later on for me to look at it though / not home right now.

nine7nine said:
kk. I'll look into this - I (obviously) do not have this problem..... What firmware images do you use?
I'm on Rogers/Canada, maybe the boot partition is a different size on some firmwares (?)....
I can also look at shrinking the boot.img, which could fix it. My boot.img is slightly bigger than the shipped boot.img and I do have an idea on how to shrink it a bit, you'll have to wait until later on for me to look at it though / not home right now.
Click to expand...
Click to collapse
32MB is the boot image max size AFAIK.

nine7nine said:
kk. I'll look into this - I (obviously) do not have this problem..... What firmware images do you use?
I'm on Rogers/Canada, maybe the boot partition is a different size on some firmwares (?)....
I can also look at shrinking the boot.img, which could fix it. My boot.img is slightly bigger than the shipped boot.img and I do have an idea on how to shrink it a bit, you'll have to wait until later on for me to look at it though / not home right now.
Click to expand...
Click to collapse
Maybe it's caused by the image size. Other custom Kernels are sized bout 13mb.
I'm running the Google Stock Build OPR3.170623.008, October 2017.
Hope you can fix it - TIA!

nine7nine said:
kk. I'll look into this - I (obviously) do not have this problem..... What firmware images do you use?
I'm on Rogers/Canada, maybe the boot partition is a different size on some firmwares (?)....
I can also look at shrinking the boot.img, which could fix it. My boot.img is slightly bigger than the shipped boot.img and I do have an idea on how to shrink it a bit, you'll have to wait until later on for me to look at it though / not home right now.
Click to expand...
Click to collapse
Personally I tried on these 2 firmwares:
sailfish-ota-opr3.170623.008
sailfish-ota-opr6.170623.012
The phone was originally a Project Fi device.. if that matters. Dev which firmware and TWRP are you using?

Warrimonk said:
Personally I tried on these 2 firmwares:
sailfish-ota->>>>opr3.170623.008<<<<<
sailfish-ota-opr6.170623.012
The phone was originally a Project Fi device.. if that matters. Dev which firmware and TWRP are you using?
Click to expand...
Click to collapse
I'm using the latest twrp-3.1.1-1 (but and idk if this makes a difference or not), I only use the twrp fastboot img (Ihave ZERO reason to actually install TWRP on my system).... and also, Others have installed and are using my kernel - so it must be a difference in firmwares / boot partition size (or image size)
Keasby said:
Maybe it's caused by the image size. Other custom Kernels are sized bout 13mb.
I'm running the Google Stock Build >>>>>OPR3.170623.008<<<<<, October 2017.
Click to expand...
Click to collapse
So yeah, I'm using a different build **OPR1.170623.027**, Oct 2017, Fi/Canada.... you both are having problems on >>>>>OPR3.170623.008<<<<< ~> Something is different in that build... If you like (and happen to have that image kicking around, you could send me the boot.img and I'll compare it to mine? later on)
I'm thinking it's not the kernel size, although - I do plan on making the kernel smaller on production builds, by reducing a lot of debugging that really isn't needed on a production build (I already have a defconfig for doing so);