The released kernels have issues like UI lags and freezes, but i found out a minor code miss on the kernel source, and i have fixed them. The kernel rebuilding is in progress, so you can give R10.0 one more try after the zips are updated again, I will post when the kernel zips are updated.
Additional changelog
Upstream kernel memory driver
Remove lz4 zram support , as zstd is better for now
Additional changelog
Upstream kernel memory driver
Remove lz4 zram support , as zstd is better for now
π27β€10π₯5π’4
On the R10.0 kernel. I found 2 issues that i can fix now
BUG 1
- Target OneUI
- Bug: OneUI's userspace lmkd and in- kernel lmkd is both alive. Killing many apps, results in poor performace
- Fix: Block userspace lmkd from killing apps
- Status: Fixed, not visible to public atm
BUG 2
- Target AOSP/OneUI
- Bug: The kernel lmk does not kill the past foreground processes, which keeps piling on memory and eventually system freezes with OOM (Out of memory)
- Fix: Do not discard foreground app list, and kill them later if they were removed from recents list
- Status: Fixed
After its all fixed, kernel zips will be updated again
BUG 1
- Target OneUI
- Bug: OneUI's userspace lmkd and in- kernel lmkd is both alive. Killing many apps, results in poor performace
- Fix: Block userspace lmkd from killing apps
- Status: Fixed, not visible to public atm
BUG 2
- Target AOSP/OneUI
- Bug: The kernel lmk does not kill the past foreground processes, which keeps piling on memory and eventually system freezes with OOM (Out of memory)
- Fix: Do not discard foreground app list, and kill them later if they were removed from recents list
- Status: Fixed
After its all fixed, kernel zips will be updated again
π36π7π₯4π3β€2
Changelog of R10.1, which is bugfix version of R10
- Block OneUI userspace lmkd from killing apps, therefore resulting in improvements on mutitasking on OneUI
- Drop UKSM (Ultra Kernel Samepage Merging), as they are seen to have high CPU usage when ram usage is high
- Add support for DeX touchpad for A40, (And A20 too since they have same tsp driver).
- Completely rewrite custom lmkd driver. Now more lower idle ram.
- Block OneUI userspace lmkd from killing apps, therefore resulting in improvements on mutitasking on OneUI
- Drop UKSM (Ultra Kernel Samepage Merging), as they are seen to have high CPU usage when ram usage is high
- Add support for DeX touchpad for A40, (And A20 too since they have same tsp driver).
- Completely rewrite custom lmkd driver. Now more lower idle ram.
π32π₯9β€2π1π1
The previous (and original) slmk driver was not good, it didnt have any code to skip, just killing based on pure memory usage, i have tried to modify some code of that driver code to make it detect whether the target is an app, foreground app, useless background app like gapps... but there was no clear way to detect it by original slmk driver. If i make it loose to keep recent task apps, then ram usage is high (>70%), else if i make it strong, the recent tab apps will all be killed.
So i completely rewrote that lmk driver, only keeping the code for killing task. Fixing these things
1. The phone freezes with high memory. This is because the lmk driver let too much processes 'pass' its checks. The code was "if the process has this priority, skip kill". Therefore the ram was flooded, also the lmk driver couldnt detect subthreads of dead app, keeping it alive so resulting in more ram usage.
So I coded to read mm usage every 0.9 secs, and if the mm usage is higher than *desired, it will kill recent task apps too. Else it is coded to never kill recent tasks.
2. Poor multitasking. As I said, the implementation of detecting foreground / background process was incomplete, so maybe background app is not killed, and foreground app is killed. However i found a fix, if the process is foreground app, it has /dev/ion opened, it is a clear solution because foreground / recent task apps will ofc use GPU, and /dev/ion should be opened for it.
* The desired memory % will be available to tune at /sys/module/simple_lmk/parameters/max,
The code is basically complete now, but sometimes random reboots because some of my coding mistakes. Currently under active tests, ETA will be today or tomorrow.
So i completely rewrote that lmk driver, only keeping the code for killing task. Fixing these things
1. The phone freezes with high memory. This is because the lmk driver let too much processes 'pass' its checks. The code was "if the process has this priority, skip kill". Therefore the ram was flooded, also the lmk driver couldnt detect subthreads of dead app, keeping it alive so resulting in more ram usage.
So I coded to read mm usage every 0.9 secs, and if the mm usage is higher than *desired, it will kill recent task apps too. Else it is coded to never kill recent tasks.
2. Poor multitasking. As I said, the implementation of detecting foreground / background process was incomplete, so maybe background app is not killed, and foreground app is killed. However i found a fix, if the process is foreground app, it has /dev/ion opened, it is a clear solution because foreground / recent task apps will ofc use GPU, and /dev/ion should be opened for it.
* The desired memory % will be available to tune at /sys/module/simple_lmk/parameters/max,
The code is basically complete now, but sometimes random reboots because some of my coding mistakes. Currently under active tests, ETA will be today or tomorrow.
π36π₯16β€5π€©5π1π±1
Any request to provide Eureka Kernel support to new devices will be discarded. We support only the Exynos7885 based devices.
We are happy and feel satisfied when people give good review about Eureka. Thanks a lot for that.β€οΈ
We are not a team who does build-boting. We focus more on improving the devices which we currently support. A kernel will never be 100% developped. There will always be development for it. If we add more devices, we will not be able to achieve this.
Moreover, as all humans, we also have a real life to cater for. We cannot spend all our time on a computer and telegram.
In case, we have more free time in future, we will decide whether we will add more devices to the support list but it's us only who will decide which next chipset to support (we need to own atleast 1 device in that chipset family).
So, kindly stop making those requests especially in our PMs.
We are happy and feel satisfied when people give good review about Eureka. Thanks a lot for that.β€οΈ
We are not a team who does build-boting. We focus more on improving the devices which we currently support. A kernel will never be 100% developped. There will always be development for it. If we add more devices, we will not be able to achieve this.
Moreover, as all humans, we also have a real life to cater for. We cannot spend all our time on a computer and telegram.
In case, we have more free time in future, we will decide whether we will add more devices to the support list but it's us only who will decide which next chipset to support (we need to own atleast 1 device in that chipset family).
So, kindly stop making those requests especially in our PMs.
β€44π15π1π1
Eureka_Kernel_R10.1_A10.zip
47.4 MB
Minor Release for A10
Eureka R10.1
Eureka R10.1
Eureka_Kernel_R10.1_A20e.zip
47.4 MB
Minor Release for A20e
Eureka R10.1
Eureka R10.1
Eureka_Kernel_R10.1_A20.zip
48.2 MB
Minor Release for A20
Eureka R10.1
Eureka R10.1
Eureka_Kernel_R10.1_A30s.zip
48.6 MB
Minor Release for A30s
Eureka R10.1
Eureka R10.1
Eureka_Kernel_R10.1_A30.zip
48.9 MB
Minor Release for A30
Eureka R10.1
Eureka R10.1
Eureka_Kernel_R10.1_A40.zip
48.6 MB
Minor Release for A40
Eureka R10.1
Eureka R10.1
π42β€10π4π1π₯1π1
Notes and changelog:
- The requested wifi driver support etc was not included, because if I enable all those configs, the boot.img containing the kernel wont fit into boot partition size. Those who want it may need to compile the kernel manually.
- Wireguard has been updated to 20200627
- Upstreamed kernel from linux 4.4 extra patches staging repo. See https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.4.y-st-rc
- simple lmk has been completely refactored, making it better. Note that more background apps are killed, They may not be able to send notifications etc.
- Switched back to KSM and defaults to disabled
- Blocked userspace lmkd from killing processes
- 100 ~ 130 swappiness is recommended
* Please do not compare the older versions and newer ones, if new one have bugs, you can just try to help the dev to fix them. Do not make the dev's efforts to this kernel to nothing, If the old one is better, then there is not reason for me to improve it more?
- The requested wifi driver support etc was not included, because if I enable all those configs, the boot.img containing the kernel wont fit into boot partition size. Those who want it may need to compile the kernel manually.
- Wireguard has been updated to 20200627
- Upstreamed kernel from linux 4.4 extra patches staging repo. See https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.4.y-st-rc
- simple lmk has been completely refactored, making it better. Note that more background apps are killed, They may not be able to send notifications etc.
- Switched back to KSM and defaults to disabled
- Blocked userspace lmkd from killing processes
- 100 ~ 130 swappiness is recommended
* Please do not compare the older versions and newer ones, if new one have bugs, you can just try to help the dev to fix them. Do not make the dev's efforts to this kernel to nothing, If the old one is better, then there is not reason for me to improve it more?
β€49π16π2π’1π1
I know this is exynos7885 group but, I do want to work on A50 kernel (exynos9610), if someone has a50 and want to test kernels, reply to this post
β€19π1π1
Recently Google has been actively killing legacy kernels, the best example that shows this is bpf. BPF, a network filter integrated into Linux kernel, were enforced starting from Android 12(S) sources, as Linux 4.4 is not a target of Google anymore. Their targets are kernels starting from version 4.14.
So, at least Linux 4.14's bpf sources is needed for the android 12 and later roms to boot. The operation is like this:
1. The bpfload event is triggered by init.rc
2. The bpfloader starts, trying to make syscalls to load the bpf objects (.o) and 'pin' to bpf filesystem at /sys/fs/bpf.
3. There are optional and non optional bpf objects, if critical ones for Android system fails to load, the bpfloader exits with status 1, so system will never boot.
So gsi devs who have to support legacy devices, made a workaround for this but this is not the point. This workaround may break in the future.
We found a bunch of bpf patches for Linux 4.4, applied them, and we made it boot till android 12L. But again Google killed it, on Android 13. The eureka kernel with bpf patches fails to boot the aosp master branch.
But, since 4.14 bpf sources will make it boot, I tried to port it and succeeded. The kernel boots with 4.14 bpf and aosp master rom. No need of extra patches
Well yeah just saying from next kernels it will support android T
So, at least Linux 4.14's bpf sources is needed for the android 12 and later roms to boot. The operation is like this:
1. The bpfload event is triggered by init.rc
2. The bpfloader starts, trying to make syscalls to load the bpf objects (.o) and 'pin' to bpf filesystem at /sys/fs/bpf.
3. There are optional and non optional bpf objects, if critical ones for Android system fails to load, the bpfloader exits with status 1, so system will never boot.
So gsi devs who have to support legacy devices, made a workaround for this but this is not the point. This workaround may break in the future.
We found a bunch of bpf patches for Linux 4.4, applied them, and we made it boot till android 12L. But again Google killed it, on Android 13. The eureka kernel with bpf patches fails to boot the aosp master branch.
But, since 4.14 bpf sources will make it boot, I tried to port it and succeeded. The kernel boots with 4.14 bpf and aosp master rom. No need of extra patches
Well yeah just saying from next kernels it will support android T
π39β€16π1π€©1
Dear users,
It is with great regret that we are going to announce this decision. We have thoroughly thought about it, but in vain.
All EurekaTeam members have come to a mutual decision that we shall EOL Eureka Kernel. However, before we EOL it, there will be a last update (no ETA please).
The kernel source will remain opensource at its current address, and you can fork it.
Anyone wishing to use the kernel source to further develop it for his own release needs to give credits to EurekaTeam.
We wish to thank everyone who supported and encouraged us to develop this kernel to the level it is today.β€οΈ
More than 1Β½ years spent together on this beautiful project.βΊοΈ
[Eureka ROMs will remain alive tho]
08/07/2022
It is with great regret that we are going to announce this decision. We have thoroughly thought about it, but in vain.
All EurekaTeam members have come to a mutual decision that we shall EOL Eureka Kernel. However, before we EOL it, there will be a last update (no ETA please).
The kernel source will remain opensource at its current address, and you can fork it.
Anyone wishing to use the kernel source to further develop it for his own release needs to give credits to EurekaTeam.
We wish to thank everyone who supported and encouraged us to develop this kernel to the level it is today.β€οΈ
More than 1Β½ years spent together on this beautiful project.βΊοΈ
[Eureka ROMs will remain alive tho]
08/07/2022
π’130β€26π8π3π1