Development [Kernel][06.12.2022][Android 13.0.0]Kirisakura 4.4.0 for Pixel 6/Pro aka "RAVIOLE"

Search This thread
Hi, I just wanted to say THANK YOU SO MUCH to @Freak07. This kernel is absolutely amazing and has made my Pixel 6 Pro into a much better phone. A lot of people have complained that Android 13 has made their devices worse in some ways, and that battery life has suffered. I'm having the complete opposite experience.

Granted, I am very much a power user, and modify every app on my device so that only specific ones can run in the background. I use App Ops and Greenify for the majority of these things. Additionally, I use the Wakelock Blocker feature of this kernel to block long-running wakelocks.

Anyway, I'm now getting under 1% of battery drain per hour, which is even better than my OnePlus 7 Pro got (and I used this kernel on that phone as well). I have exactly 300 apps right now and getting battery life like this with that number of apps is almost unheard of. This is only possible because of this kernel. My phone's performance hasn't suffered in any way, shape, or form either. In fact, it's faster than ever, and I'm generally very picky about performance.

Basically, I'm very very happy with this phone all because of this kernel! It has definitely made life easier, and I'm very thankful for all the work you've put into it. I'm very excited to see what comes in the future!
 

Attachments

  • Screenshot_20220829-011226~2.png
    Screenshot_20220829-011226~2.png
    186.1 KB · Views: 183

Zetsubou Sensei

Senior Member
Sep 19, 2012
95
21
Google Pixel 4 XL
I'm not a very techy person, but my Google Pixel 6 pro keeps overheating way too fast when playing games. The only way this phone charges is if i lay it under an ice pack.

I don't quite understand the directions in order to install these packages, is there a way for simpler instructions to be added? I don't understand a lot of these terms.
As @triggerhappy_ said, if you're not a "techy person" I would recommend NOT doing this.

There is always a chance you may *permanently* destroy your phone. If that's a financial risk you're willing to take as someone who doesn't have the experience to try to remedy it, go for it.

To be clear, you could do everything right and still have something fail bc your computer hiccuped during a critical file transfer. Unless you're willing to potentially spend hours bringing your device back from an unwarranty-able dead, do NOT do this.
 
I'm experiencing a strange bug. I'm on Android 13 and my CPU literally can't go above 1197MHz or 1436 MHz on the fastest cores, even when the screen is on. If I understand the AK3 module correctly, it's supposed to limit the CPU while the screen is off, and then go back to normal when it turns back on. This isn't happening unfortunately.

And even in EXKM, I can't change the max CPU frequency at all. It just changes right back.

Is there anything you can do about this? I can't play certain games at all. The CPU is too limited.

Additionally, I don't have any apps that are authorized to use root that would modify the CPU in any way, shape, or form (I even disabled EXKM's root access). And I just have the AK3 module in Magisk. So nothing should be causing this. Also, this happens even after a reboot. And I'm not experiencing thermal throttling. I even tried putting my phone in the freezer for a while. No change.
 

Attachments

  • Screenshot_20220831-232700.png
    Screenshot_20220831-232700.png
    230.7 KB · Views: 111
Last edited:

Freak07

Recognized Developer / Recognized Contributor
Jan 2, 2011
5,908
20,217
I'm experiencing a strange bug. I'm on Android 13 and my CPU literally can't go above 1197MHz or 1436 MHz on the fastest cores, even when the screen is on. If I understand the AK3 module correctly, it's supposed to limit the CPU while the screen is off, and then go back to normal when it turns back on. This isn't happening unfortunately.

And even in EXKM, I can't change the max CPU frequency at all. It just changes right back.

Is there anything you can do about this? I can't play certain games at all. The CPU is too limited.

Additionally, I don't have any apps that are authorized to use root that would modify the CPU in any way, shape, or form (I even disabled EXKM's root access). And I just have the AK3 module in Magisk. So nothing should be causing this. Also, this happens even after a reboot. And I'm not experiencing thermal throttling. I even tried putting my phone in the freezer for a while. No change.
That's normal behaviour. You're not supposed to change the min/max cpufreqs manually.

Thermal-hal and power-hal both control these dynamically, based on device temperature and certain scenarios like touching the screen, opening apps, camera etc. If you change them, those will immediately change it back.

If you tap the live frequency view in exkm you'll see it uses higher freqs as well on the frequency distribution. Or hit reset in the frequency distribution, navigate a bit through your phone, open a few apps and check again.

If thermal-hal is active and restricts freqs constantly, you're running into thermal throttling.

Edit: @Phascinate you might have forgotten you enabled the batterysaver mode in CleanSlate config app. That restricts to exactly those freqs too.
 
Last edited:

Freak07

Recognized Developer / Recognized Contributor
Jan 2, 2011
5,908
20,217
Update to 4.1.6

Hey guys and girls,

I hope everyone started into a good week. Here´s the next release. Kind of a surprise update from Google, I suspected it would drop next Monday.
But here we go, the next update including the September security patch. The updates to the main kernel we already had in advance by having upstream merged. The other change is in the bms submodule, which controls charging.

Amongst linux-stable upstream there are a few other updates in this kernel, which I´ll mention shortly in the changelog.

Kernel is compiled for stable A13, not A13 QPR Beta!


I wish everyone a nice day.

If you´re one of the unfortunate ones that suffer from the device is corrupt bug on pixel 6 series please take a look at the FAQ at the beginning of this thread it contains a solution. The issue is probably caused by a bug that affects pixel 6 devices and has nothing to do with magisk or a kernel, it just happens to get triggered when using any of those.



Changelog:

- Linux-Stable bumped to 5.10.141
- scheduler improvements from linux-mainline
  • sched: Allow newidle balancing to bail out of load_balance
    [*]sched/fair: Introduce SIS_UTIL to search idle CPU based on sum of util_avg
    [*]nohz/full, sched/rt: Fix missed tick-reenabling bug in dequeue_task_rt()
    [*]sched/core: Do not requeue task on CPU excluded from cpus_mask
- updates from kernel/common


Download:


If you´re coming from another kernel restore stock boot.img, dtbo.img, vendor_boot.img and vendor_dlkm.img before flashing. Thank you.

I wish everybody a great day/evening!
Have fun, enjoy the kernel and your phone.



If you like my work please consider a donation.
Donations are not mandatory but very welcome.
If you like my work and want to buy me a coffee/green tea: http://paypal.me/freak07
 
Last edited:

Gordietm

Senior Member
Sep 11, 2012
2,133
629
Toronto
Google Pixel 7
Google Pixel 7 Pro
Update to 4.1.6

Hey guys and girls,

I hope everyone started into a good week. Here´s the next release. Kind of a surprise update from Google, I suspected it would drop next Monday.
But here we go, the next update including the September security patch. The updates to the main kernel we already had in advance by having upstream merged. The other change is in the bms submodule, which controls charging.

Amongst linux-stable upstream there are a few other updates in this kernel, which I´ll mention shortly in the changelog.


I wish everyone a nice day.

If you´re one of the unfortunate ones that suffer from the device is corrupt bug on pixel 6 series please take a look at the FAQ at the beginning of this thread it contains a solution. The issue is probably caused by a bug that affects pixel 6 devices and has nothing to do with magisk or a kernel, it just happens to get triggered when using any of those.



Changelog:

- Linux-Stable bumped to 5.10.141
- scheduler improvements from linux-mainline
  • sched: Allow newidle balancing to bail out of load_balance
    [*]sched/fair: Introduce SIS_UTIL to search idle CPU based on sum of util_avg
    [*]nohz/full, sched/rt: Fix missed tick-reenabling bug in dequeue_task_rt()
    [*]sched/core: Do not requeue task on CPU excluded from cpus_mask
- updates from kernel/common


Download:


If you´re coming from another kernel restore stock boot.img, dtbo.img, vendor_boot.img and vendor_dlkm.img before flashing. Thank you.

I wish everybody a great day/evening!
Have fun, enjoy the kernel and your phone.



If you like my work please consider a donation.
Donations are not mandatory but very welcome.
If you like my work and want to buy me a coffee/green tea: http://paypal.me/freak07
Thanks for the quick update. Donation sent. 😀
 

S8rooted&tooted

Senior Member
Sep 18, 2017
393
202
Google Pixel 3 XL
Google Pixel 6 Pro
I can confirm the frequency problems with AK3 and or kernel to stock. Just updated to see what would happen during start. Mine stayed at max frequencies on all cores then slowly came back down. With AK3 it didn't allow it to max out cores during boot. Using AK3 for me has always given problems. Mine also would hold during sleep at about middle frequency on all and not drop. My middle frequency on all cores would have most time and minimal on sleep and max. Just after updating to September patch and stock kernel, after just 10 minutes I see time on all different frequencies on all cores.. I noticed once custom kernels started using AK3, this has been an issue for me. Also, if the frequencies are dependent on system processes, why would a module be needed to hold those down? Wouldn't that conflict like changing them ourselves? System processes control it but the module limits it, right there sounds like a conflict if system processes need higher frequency with the screen off.
 
  • Like
Reactions: Freak07

Freak07

Recognized Developer / Recognized Contributor
Jan 2, 2011
5,908
20,217
I can confirm the frequency problems with AK3 and or kernel to stock. Just updated to see what would happen during start. Mine stayed at max frequencies on all cores then slowly came back down. With AK3 it didn't allow it to max out cores during boot. Using AK3 for me has always given problems. Mine also would hold during sleep at about middle frequency on all and not drop. My middle frequency on all cores would have most time and minimal on sleep and max. Just after updating to September patch and stock kernel, after just 10 minutes I see time on all different frequencies on all cores.. I noticed once custom kernels started using AK3, this has been an issue for me. Also, if the frequencies are dependent on system processes, why would a module be needed to hold those down? Wouldn't that conflict like changing them ourselves? System processes control it but the module limits it, right there sounds like a conflict if system processes need higher frequency with the screen off.
Thanks for the report. I´ll try to clear it up a bit for you.
I don´t know what other kernels do exactly, as I´m usually not following them very closely, but I can answer for my project.

The cores not maxed out constantly for two minutes directly after restart are by design. What you´re seeing is the PMU limiter restricting the frequencies, because the threshold for requesting more performance is not crossed. This prevents a lot of additional heat. Especially the higher frequencies are "inefficient" in more than one way. There´s a higher than linear increase in heat/powerdraw vs performance increase.
The PMU limiter feature is described in detail following this link. I suggest to give a good read, because this is vital background information for everything I´m trying to explain below. :)
Please note: The PMU limiter does not operate in this manner on the stock kernel.

If you use a CPU-Frequency overlay you will see higher frequencies are being used during app launches, like in the screenrecord below. Notice that this is not a real-time representation of what´s actually happening on the phone. So you can´t draw any definitive conclusions about it. Frequencies change much much faster than those overlays, or the live freq view in EXKM can show to a user. (Many many times in a 10th of a second) But to explain this topic in a simplified manner is possible with it.



For the explanation below keep the limits of the PMU limiter based on different conditions in mind. And also keep in mind that PMU limiter doesn't hard limit, it just limits higher freqs until a certain threshold of requested performance is crossed
You'll see at first I start devcheck app. The app is still in memory, that's why the cores don't max out on the overlay. (that doesn´t mean that max freq is not used for the fraction of a second, just the overlay won´t catch it) There's not much to load on the page that's being opened either on the app. Going back to the start page of devcheck, there are more elements in the UI, hence bigger freq bump.

Launching CPU benchmark app and running it, you'll see big cores are maxing out when max performance is requested by running the workload of this benchmark. During this benchmark the workload gets scheduled mostly to the big cores (you can't see this with apps or overlays just by tracing the scheduler). That's why you see max cores max out crossing the PMU limiter threshold easily.

EXKM app is cold launched. I force closed the app before the screen recording so it needs to be loaded completely from scratch. You'll see max freqs are reached, PMU limit for app launches (2,4ghz for big cores) is crossed during the launch to load the app as fast as possible.

Now here's the cpufreq distribution taken from exkm on my end since flashing yesterday evening.


All frequencies are being utilized on all cores. But you can also see the PMU limiter is doing its job. Let's take the efficient cluster with the little cores as example.
You'll see the maxfreq of 1.8ghz for little cores is utilized most of all higher freq steps (1.19GHZ and above). But you can also see the PMU limiter is kicking in, as 1.19GHZ and 1.4GHZ are just after that.

All of this is expected. This works completely different from stock and it's expected that you will be able to tell differences.

Now how does that tie in with other system processes?
The AK3 module you´re seeing in magisk manager after flashing this kernel allows to replace certain parts of those system processes, so that those work with the changes done on the kernel side. The kernel isn't a unit that stands just for it alone.

Example: The PMU limiting itself is done via kernel. But the different conditions on which PMU limiting is triggered (launching apps, 120fps, scrolling, display idle, screen content moving, etc, etc) are detected and handled not by the kernel side, because the system just has more information what's currently happening.
Same for the thresholds of the PMU limiting. The system detects what is happening on your phone like scrolling, screen content static, screen content moving, app launching etc, and different thresholds for the PMU limiting are set.
This information is fed to the kernel via the powerhal, so it can do its job.


You'll notice a difference in freq distribution on this kernel to stock, as it's a deliberate change.
Read the linked posts and I think you'll understand. I'm here for questions.
But keep in mind. All those end-user focused UI tools like CPU freq overlays, live freqs in exkm don't reflect what's actually happening, just give a rough idea. There's a lot of room for misinterpretation.
 
Last edited:

S8rooted&tooted

Senior Member
Sep 18, 2017
393
202
Google Pixel 3 XL
Google Pixel 6 Pro
Thanks for the report. I´ll try to clear it up a bit for you.
I don´t know what other kernels do exactly, as I´m usually not following them very closely, but I can answer for my project.

The cores not maxed out constantly for two minutes directly after restart are by design. What you´re seeing is the PMU limiter restricting the frequencies, because the threshold for requesting more performance is not crossed. This prevents a lot of additional heat. Especially the higher frequencies are "inefficient" in more than one way. There´s a higher than linear increase in heat/powerdraw vs performance increase.
The PMU limiter feature is described in detail following this link. I suggest to give a good read, because this is vital background information for everything I´m trying to explain below. :)
Please note: The PMU limiter does not operate in this manner on the stock kernel.

If you use a CPU-Frequency overlay you will see higher frequencies are being used during app launches, like in the screenrecord below. Notice that this is not a real-time representation of what´s actually happening on the phone. So you can´t draw any definitive conclusions about it. Frequencies change much much faster than those overlays, or the live freq view in EXKM can show to a user. (Many many times in a 10th of a second) But to explain this topic in a simplified manner is possible with it.



For the explanation below keep the limits of the PMU limiter based on different conditions in mind. And also keep in mind that PMU limiter doesn't hard limit, it just limits higher freqs until a certain threshold of requested performance is crossed
You'll see at first I start devcheck app. The app is still in memory, that's why the cores don't max out on the overlay. (that doesn´t mean that max freq is not used for the fraction of a second, just the overlay won´t catch it) There's not much to load on the page that's being opened either on the app. Going back to the start page of devcheck, there are more elements in the UI, hence bigger freq bump.

Launching CPU benchmark app and running it, you'll see big cores are maxing out when max performance is requested by running the workload of this benchmark. During this benchmark the workload gets scheduled mostly to the big cores (you can't see this with apps or overlays just by tracing the scheduler). That's why you see max cores max out crossing the PMU limiter threshold easily.

EXKM app is cold launched. I force closed the app before the screen recording so it needs to be loaded completely from scratch. You'll see max freqs are reached, PMU limit for app launches (2,4ghz for big cores) is crossed during the launch to load the app as fast as possible.

Now here's the cpufreq distribution taken from exkm on my end since flashing yesterday evening.


All frequencies are being utilized on all cores. But you can also see the PMU limiter is doing its job. Let's take the efficient cluster with the little cores as example.
You'll see the maxfreq of 1.8ghz for little cores is utilized most of all higher freq steps (1.19GHZ and above). But you can also see the PMU limiter is kicking in, as 1.19GHZ and 1.4GHZ are just after that.

All of this is expected. This works completely different from stock and it's expected that you will be able to tell differences.

Now how does that tie in with other system processes?
The AK3 module you´re seeing in magisk manager after flashing this kernel allows to replace certain parts of those system processes, so that those work with the changes done on the kernel side. The kernel isn't a unit that stands just for it alone.

Example: The PMU limiting itself is done via kernel. But the different conditions on which PMU limiting is triggered (launching apps, 120fps, scrolling, display idle, screen content moving, etc, etc) are detected and handled not by the kernel side, because the system just has more information what's currently happening.
Same for the thresholds of the PMU limiting. The system detects what is happening on your phone like scrolling, screen content static, screen content moving, app launching etc, and different thresholds for the PMU limiting are set.
This information is fed to the kernel via the powerhal, so it can do its job.


You'll notice a difference in freq distribution on this kernel to stock, as it's a deliberate change.
Read the linked posts and I think you'll understand. I'm here for questions.
But keep in mind. All those end-user focused UI tools like CPU freq overlays, live freqs in exkm don't reflect what's actually happening, just give a rough idea. There's a lot of room for misinterpretation.
I have used this kernel on this device and many others. Like the pixel 3 xl.. I stopped using kernels once AK3 was introduced. Problems across many devices. I tried helping the issue before, but can't help someone who thinks OnePlus is the defacto on Android. I used a few different UI apps to all see the same frequency issues. Now it's been a day since I updated, and I can see without a restart since yesterday, all my frequencies have been used at one time or another. Not real time but total calculated time via UI app. Dev check to be specific. I read your post and the last frequency set you list is the only one my phone ever used.. max frequencies would be stuck at that set you list and lowest possible frequency would go to variable.. battery drop whenever using the phone with games. And hard..like 10% in 10 minutes. Maybe get a total of 2 hours screen time total all day. I am at 2 hours screen time right now and have 83% battery. That is great for me. The past month has been charge the phone by lunch if I use anything that needed high power, my theory, it didn't get to use the high power therefore it would over use battery to compensate for not being able to run higher frequencies. Also lag issues once in awhile watching movies, buffering on perfect cell reception. Most of the time the kernel worked great. But, I would get once in awhile a freeze when opening the phone(not being able to go into higher frequencies). This was never an issue before on stock and isn't now. OnePlus isn't android. AK3 dev uses OnePlus as his defacto. He should use AOSP or a Pixel as defacto. That is the biggest issue with AK3.
 
  • Haha
Reactions: Mrcactuseater

Freak07

Recognized Developer / Recognized Contributor
Jan 2, 2011
5,908
20,217
I have used this kernel on this device and many others. Like the pixel 3 xl.. I stopped using kernels once AK3 was introduced. Problems across many devices. I tried helping the issue before, but can't help someone who thinks OnePlus is the defacto on Android. I used a few different UI apps to all see the same frequency issues. Now it's been a day since I updated, and I can see without a restart since yesterday, all my frequencies have been used at one time or another. Not real time but total calculated time via UI app. Dev check to be specific. I read your post and the last frequency set you list is the only one my phone ever used.. max frequencies would be stuck at that set you list and lowest possible frequency would go to variable.. battery drop whenever using the phone with games. And hard..like 10% in 10 minutes. Maybe get a total of 2 hours screen time total all day. I am at 2 hours screen time right now and have 83% battery. That is great for me. The past month has been charge the phone by lunch if I use anything that needed high power, my theory, it didn't get to use the high power therefore it would over use battery to compensate for not being able to run higher frequencies. Also lag issues once in awhile watching movies, buffering on perfect cell reception. Most of the time the kernel worked great. But, I would get once in awhile a freeze when opening the phone(not being able to go into higher frequencies). This was never an issue before on stock and isn't now. OnePlus isn't android. AK3 dev uses OnePlus as his defacto. He should use AOSP or a Pixel as defacto. That is the biggest issue with AK3.
I can't reproduce any of those issues.

But if stock is working fine for you, just use stock. 👍

I'm sorry but this thread is not about AK3, so I won't comment on anything regarding, also due to the fact that a few of those statements have no basis in fact.
There's a thread for AK3 on XDA.
 
Last edited:

Badger50

Senior Moderator
Staff member
Moderator Announcement
Thread aggressively cleaned! A friendly reminder to all. While it is always ok to ask legitimate questions of any Developer, starting an OT slugfest is definitely not ok!
Please be aware that posting argumentative statements, and responding to these statements with your own rebuttals is disrepectful at best to the thread owner who contributes
countless hours to his kernels in order to share them for free on XDA. So please just report member misconduct, and let the Mods take it from there.

Going forward. Should this occur again, I will have no hesitation in banning members from participating in this thread out of respect for the Developer
and in accordance with XDA Rules for member conduct:

2.3 Flaming / Lack of respect: XDA is about sharing and this does not involve virtual yelling (flaming) or rudeness. Flaming or posting with a lack of respect is unacceptable. Treat new members in the manner in which you would like to have been treated when you were a new member. When dealing with any member, provide them with guidance, advice and instructions when you can, showing them respect and courtesy. Never post in a demanding, argumentative, disrespectful or self-righteous manner.​

So please, keep this thread on topic and respectful to the Developer as well as towards each other. As a member of XDA for 11 years, I have seen more than one Developer
leave XDA due to this kind of behavior, which we definitely do not want to see. After all, without the Dev's, what would we have to talk about??

Thank you all for your cooperation, and a pleasant day to all.

-Best regards: Badger50
 

reddvilzz

Senior Member
May 29, 2012
1,938
392
Jakarta
OnePlus 9
Google Pixel 6 Pro
Hi, I was trying to restore the stock image after installing the kernel for an OTA update.

I already removed the magisk modules and uninstall magisk, then adb reboot bootloader
but on the bootloader my devices can't be detected

what seems to go wrong? I tried installing the latest usb driver from google and rebooted but when I type adb devices it won't show anything.
and now I can't start my phone, it will bootloop back to recovery
 

Freak07

Recognized Developer / Recognized Contributor
Jan 2, 2011
5,908
20,217
Hi, I was trying to restore the stock image after installing the kernel for an OTA update.

I already removed the magisk modules and uninstall magisk, then adb reboot bootloader
but on the bootloader my devices can't be detected

what seems to go wrong? I tried installing the latest usb driver from google and rebooted but when I type adb devices it won't show anything.
and now I can't start my phone, it will bootloop back to recovery
If you uninstall magisk it will restore stock boot.img. Since this kernel modifies other partitions as well (including boot.img), you need to restore those too, otherwise you end up with a Frankenstein device that won't work. (boot.img from stock firmware, other partitions from my kernel)
To restore to stock images please read the FAQ, it mentions the partitions you need to flash.

Sounds like your fastboot drivers are not up to date, if the device is not detected in fastboot/bootloader.

So the easiest now is to dirty flash the firmware you're currently on, either via factory image or try the web tool as both will restore all the partitions. If you haven't already done so, make sure to flash A13 firmware to both slots.
 
Last edited:

Top Liked Posts

  • 1
    Had to donate... My battery life on p6 has improved dramatically... This is a massive update and now I'm really lovin my phone. 5g UC used to kill my battery now it's almost like having on 4g lte drainage. I almost want to switch back to lte to see how crazy the battery life is there now however, I'ma leave it on 5g from now on. Really appreciate the time and effort.
    same here, used to end a day of light usage on like 15% but now it's more like 60-70%
  • 27
    Update to 4.4.0

    Hey guys and girls,

    I hope everyone started well in the new week. Here´s the next release and it´s a really big one. I know some of you already peeked over to the Pixel 7/Pro forums and asked if the changes from there will also find their way to the Pixel 6/Pro release.
    The answer is yes, except one change that´s not easy to cleanly implement as of now. If I´m going to implement something I want it to be done cleanly so that I´m content and happy releasing it, as of now this didn´t work out as I hoped. If time allows I plan to revisit that in the future however.

    This release includes the QPR (quartly platform release) changes and is now on the same state as A13 QPR Beta was previously. You need to be on December firmware release to be able to install this kernel!

    This release features a few major changes, which I want to explain in greater details, so excuse the longer release post. I´d appreciate if everyone takes the time to at least read it. :)

    MGLRU V15
    Amongst the QPR changes from Google, which are a big step ahead of the initial A13 release (always the case the last years, the december update fixes tons of things of the major android version bump), MGLRU was bumped to latest V15 state, which was also merged to the linux-kernel recently. Was testing this out for nearly a month, before releasing. For those interested about MGLRU, here´s an excellent writeup by @MishaalRahman.


    Introduction of Lazy RCU
    1.1.0 has the entire(!) RCU subsystem updated to latest linux 6.0 kernel state. This also allowed for Lazy RCU to be merged into the kernel, which should result in power-savings while the device is lightly-loaded or idling (which is basically the case all the time a smartphone isn´t being interacted with (nothing touching the screen and no other workload such as video editing is done).
    If you´re interested in details check the slides, which are also linked in the article I linked above.
    A very simplified explanation: RCU functionality can be called 1000s of times a second, batching RCU calls can save power by not calling as often.

    That´s one of the changes I wanted to be tested extensively, as there are a few 10000 lines of code changes.

    Please keep in mind, those are kernel changes and battery life will not be improved magically by huge amounts, due to such a change, even if the change itself is massive.
    Example: If you raise or lower the display brightness by around 10% over an entire day, you´ll see a bigger impact.
    Reading the OP gives you a good idea what this project is about! :)

    Playback over USB C to 3.5mm Dongles
    Some users were experiencing issues while using usb-c to 3.5mm dongles while running my kernel. After a long time I finally discovered how to reproduce the bug as the logs did not point towards any kernel error. It happens only if default usb configuration in developer options is set to anything else than "no data transfer". If "no data transfer" is selected there´s no issue at all. (that´s why I wasn´t able to reproduce the behaviour)
    A few commits from linux-stable for the usb dwc3 driver breaks playback when screen is shut off or cycling through the "default usb configuration" settings, which causes the aoc driver that´s responsible for playback to shut down.
    Reverting those commits fixes the issue.

    Thanks to @WhoIsJohnGalt1979 and @Hurt Copain for nagging me about the issue and providing logs, I finally found a way to reproduce the issue so I was able to debug it.

    Given that playback is "glitchy" (a brief audio stutter) on stock kernel as well, when either cycling through different "default usb configuration" settings or turning screen on/off, that driver and the framework part in regards to the different USB default configuration states is generally very wonky. That´s probably also why selecting default USB configuration is "hidden away" in developer options.


    I´d like to write all of this with more detail, but at the moment I lack the time to do so.

    Kernel is compiled for stable A13!


    I wish everyone a nice day.

    If you´re one of the unfortunate ones that suffer from the device is corrupt bug on pixel 6 series please take a look at the FAQ at the beginning of this thread it contains a solution. The issue is probably caused by a bug that affects pixel 6 devices and has nothing to do with magisk or a kernel, it just happens to get triggered when using any of those.



    Changelog:

    - Import December QPR changes
    - Linux-Stable bumped to 5.10.157
    - Bump prebuilt clang to latest 16.0.1 from Google
    - important improvements and fixes to binder
    - bump MGLRU to latest V15 state
    - Backport entire RCU subsystem to linux 6.0
    - Lazy RCU which should result in power-savings while the device is lightly-loaded or idling, more information here
    - Fix audio playback stopping for some users when turning screen off (thanks for @WhoIsJohnGalt1979 and @Hurt Copain for nagging me about the issue and providing logs)
    - improve CPU throttling behaviour
    - fix to memory management
    - improvements from linux-mainline for several subsystems
    • scheduler
      • 02595c9fb4ec sched/core: Fix comparison in sched_group_cookie_match()
        407e4ccbb158 sched/fair: Move call to list_last_entry() in detach_tasks
        0ea56a65b686 sched/fair: Cleanup loop_max and loop_break
        0461c9736ec2 sched/fair: Make sure to try to detach at least one movable task
        f2489ca21b11 sched/fair: Cleanup for SIS_PROP
        5a3074a7ac79 sched/fair: Default to false in test_idle_cores()
        bb95868debb0 sched/fair: Remove useless check in select_idle_core()
        50112e040e6a sched/fair: Avoid double search on same cpu
        2457687f35d3 sched/fair: Remove redundant check in select_idle_smt()
    • memory management
      • 6bf69138a12b mm: rename p4d_page_vaddr to p4d_pgtable and make it return pud_t *
        9819fcefb782 mm: rename pud_page_vaddr to pud_pgtable and make it return pmd_t *
        997cdba71861 mm: add vma_lookup(), update find_vma_intersection() comments
        eb1eccad20cb mm/page_alloc: fix obsolete comment in deferred_pfn_valid()
        1f30d4f3fb20 mm/page_alloc: remove obsolete gfpflags_normal_context()
        17dd220de848 mm/page_alloc: use costly_order in WARN_ON_ONCE_GFP()
        4d7be8d8d6d4 mm/page_alloc: init local variable buddy_pfn
        521b49f4067c mm/page_alloc: use helper macro SZ_1{K,M}
        9838ea6feaee mm/page_alloc: use local variable zone_idx directly
        d049e3821e8b mm/page_alloc: add missing is_migrate_isolate() check in set_page_guard()
        5dc1c3c60469 mm: remove obsolete pgdat_is_empty()
        55e89c7708e3 mm/page_alloc: fix freeing static percpu memory
        bd801ed8eace mm/page_alloc: add __init annotations to init_mem_debugging_and_hardening()
        ce00e122335e mm/page_alloc: remove obsolete comment in zone_statistics()
        cc20df37215b mm: remove obsolete macro NR_PCP_ORDER_MASK and NR_PCP_ORDER_WIDTH
        97e15d20dd79 mm/page_alloc: make zone_pcp_update() static
        f7425d856d30 mm/page_alloc: ensure kswapd doesn't accidentally go to sleep
        236a9831f7e4 mm: add merging after mremap resize
        bd1537226f30 mm: mremap: fix sign for EFAULT error return value
        4fe39974c254 mm/mremap: avoid unneeded do_munmap call
        3983a53d85a6 mm/mremap:: use vma_lookup() instead of find_vma()
        b832f38c3630 mm, hugepages: add mremap() support for hugepage backed vma
        23aa8d328a4c mm/mremap: allow arch runtime override
        b029910a3ec8 mm/mremap: use pmd/pud_poplulate to update page table entries
        53093a2f034d mm/mremap: don't enable optimized PUD move if page table levels is 2
        c7b8580c66ff mm/mremap: convert huge PUD move to separate helper
        d7e1ce9e582e mm/mremap: fix memory account on do_munmap() failure
        a2a195324435 mm/mremap: use vma_lookup() in vma_to_resize()
        7f87797e053b mm/mremap: don't account pages in vma_to_resize()
        bbebb360b5e2 mm: forbid splitting special mappings
        9fce5b920e9d mremap: check if it's possible to split original vma
        089557da4960 vm_ops: rename .split() callback to .may_split()
        c180d1867972 mremap: don't allow MREMAP_DONTUNMAP on special_mappings and aio
        e7404be1ba61 mm/mremap: for MREMAP_DONTUNMAP check security_vm_enough_memory_mm()
        5bae8c6fbfff mm/mremap: account memory on do_munmap() failure
        281904d82593 mm: refactor of vma_merge()
    • PSI
      • d95535a6cabf sched/psi: Fix periodic aggregation shut off
        73abf1a6b993 psi: dont alloc memory for psi by default
        UPSTREAM: psi: Fix psi state corruption when schedule() races with cgroup move
        df3995427bf1 sched/psi: Remove unused parameter nbytes of psi_trigger_create()
        feb99cdbd69e psi: Fix PSI_MEM_FULL state when tasks are in memstall and doing reclaim
        83fc90cd1a63 psi: Reduce calls to sched_clock() in psi
        f6af1db49cbd psi: Optimize task switch inside shared cgroups
        317f29565dd3 psi: Pressure states are unlikely
        7e17bae683a3 psi: Use ONCPU state tracking machinery to detect reclaim
        118d212fd15e psi: Add PSI_CPU_FULL state
    • more details please check github
    - patches to f2fs to sync with latest f2fs-stable
    - binder fix
    - updates from kernel/common to several subsystems
    - import all improvements from google QPR to powerhint module
    - tweak powerhal for improved performance/efficiency
    • Dynamically adjust target load for memory interface during interaction.
    - other fixes please check github


    Download:
    Attached to release post as AFH does not allow me to upload files at the moment.
    I´ll push to AFH once it´s back up.



    If you´re coming from another kernel restore stock boot.img, dtbo.img, vendor_boot.img and vendor_dlkm.img before flashing. Thank you.

    I wish everybody a great day/evening!
    Have fun, enjoy the kernel and your phone.



    If you like my work please consider a donation.
    Donations are not mandatory but very welcome.
    If you like my work and want to buy me a coffee/green tea: http://paypal.me/freak07
    15
    Important

    Just a heads up for everyone:

    If the firmware update that's going to drop most likely today contains the QPR (=quarterly platform release, so the changes currently tested in the QPR A13 Beta) amongst the pixel feature drop, don't flash the current release of the kernel until I update the kernel with the new sources!

    Otherwise there might be issues or the device refuses to boot due to the new firmware requiring the necessary kernel changes as well!

    I'll try to update as fast as possible, but depending on how much conflicts there are and how fast google pushes the new source, merging the new source it might take a bit.
    9
    Why is A13 QPR not supported?
    There are sources for QPR Beta available, that´s not the problem.

    Copy paste from another post in this thread where I already answered the question, why I don´t support dev-previews/betas:

    No, I have no plans to support A13 beta or any dev-preview or beta firmware. It will be supported once it´s stable. I don´t have the time, desire and motivation to support it.
    It all boils down to the fact that I enjoy doing what I´m doing here, I do it in my free time and share what I´m using myself with others so they can enjoy it with me and I want to release something that´s polished, extensively tested and stable.

    Since that questions comes up from time to time:

    I´m not comfortable releasing something I´m not running/testing extensively myself with loads of changes compared to the stock base.
    I never felt the urge to do beta testing for companies just to run more recent software too.

    I don´t have time to test, maintain and build that many compilations, let alone switching between Beta Firmware and Stable firmware on my phone for testing. It´s simply not possible, and I don´t want to release something that´s not extensively tested.
    I think sometimes people don´t realize how much time goes into this aspect of my kernels projects alone.

    Also try to see it that way:
    Merging code updates takes time. Be it linux-stable, f2fs-stable, kernel/common, lrng updates, updates directly from Google or a lot of the features that are descrbied in the OP. Sometimes longer, sometimes shorter.
    This kernel is now very very far from the stock base (compared to the other kernels available) as is also reflected in the OP. So while merging code updates will take time as there are many conflicts that need to be solved on my kernel. Even if the branches are somewhat similar I still need a lot of additional time to manage this aspect alone, not to speak of testing on my device to make sure nothing is broken.

    There´s no longer just the kernel repo itself to manage. With the introduction of GKI, the kernel is split in several sub repos for different device specific drivers, touchscreen, wifi, uwb, nfc, bt, etc etc. Those needs to be managed too, as well as other repos from the build environment as they´re different between stable and beta.
    Powerhal changes need to be monitored and adjusted each month too, as there might be differences between stable and beta as well.

    Building takes time. Every compilation, for testing or release purposes takes about 15 minutes. Only building, not adjusting the code. Every release here needs 2 different builds for oriole/raven. Yes I can do something else during the compilation, but it´s still time I need to spend.


    Ohhh .. So no kirisakura kernel option available... That's a bummer...
    Is there a Telegram group?
    No there´s no telegram group. Everything you need is here on XDA. All information is in the first few posts. If you use the search function you´ll find even more I guess.
    6
    I doubt "Now Playing" has anything to do with it. I have that enabled and am getting excellent idle drain on stock kernel.
    Neither do I have a problem running my kernel with now playing enabled :)

    And generally the kernel has not much to with idle drain. Network coverage, wifi signal, usage patterns, usage and not to speak of apps and services running in the background have far more impact compared to a kernel. :)
    5
    Thank you!
    Just did the update/flash. Running kernel v4.3.0 smoothly on the Nov 2022 release.
    Thank you for the kernel update and for getting far ahead of the actual patches. Restore to stock instructions worked as expected. V4.3 working beautifully on Nov update.
    Thanks for the kind words and I´m glad it´s working fine for you. Enjoy the ride!

    Looks like I'm switching back from the beta to stable... I knew I'd end up doing this.. can't help but to run your kernel! Thanks for the new update as always sir.
    Appreciate the kind words :)
    I stopped doing beta testing for big tech companies a while ago :D especially since the betas are mostly testing only platform changes and no pixel features in advance. But I know the feeling of excitement and running something bleeding edge still quite well. (that´s why latest google prebuilt clang is used in this project for example ;) )

    i uninstalled 4.2.0 while i was on October 2022 and updated to November 2022, i updated KF to alpha 12 first, then i installed 4.3.0

    i rebooted my pixel, and after roughly 5 seconds when it displays "Google," it cuts to black, then boots into "Fastboot Mode" instead

    enter reason states "reboot bootloader" (and no visible errors, weirdly enough)

    i got out of the bootloop by just dirty flashing the factory image, but the other boot slot is still unbootable if i try to switch to it

    i've attached the ak3 log from when i was installing 4.3.0, though i doubt it'll be of any help since i've legitimately never had this happen to me before with custom kernels...? it's bizarre


    View attachment 5756801
    That is bizarre. There are many possible causes. You may want to ensure you flash the factory image to both slots and wipe data to get back to square one to eliminate the issue with the unbootable slot a.
    the log looks fine from a quick glance. I don´t know why it isn´t working for you.
    Flashing the factory image will not change slots. The factory image will always flash to the current slot, compared to a full OTA zip, which will flash to the currently inactive slot and switch to the updated previously inactive slot upon successful installation and the next boot.

    So @phaino00 ´s advice to make sure to flash to both slots is a good one!
  • 115
    Kirisakura-Kernel for the Pixel 6/Pro

    Hello everyone,

    To keep it short: Here is Kirisakura - Kernel for the Google Pixel 6 Pro aka Raven and the Pixel 6 aka Oriole, together Raviole.
    I would appreciate if everybody that flashes the kernel, reads at least once through this opening post and the following ones.

    The kernel aims to keep most of the subsystems updated, way ahead of the stock kernel, thereby improving security, stability and performance!
    This includes Linux-Stable, F2FS-Stable and kernel/common!
    If that got you curious, have a read about linux-stable and why it is important here. The stable-process is not the same for every subsystem, but the general idea, rule of thumb and benefits are applicable for other subsystems as well.

    The kernel includes a lot of improvements and contributions from other developers as well. Without this kernel would not exist.
    A big part of improvements originate from @arter97´s, @kdrag0n´s and @Sultanxda´s work. Many others contributed in some way or another to this kernel.
    A big thanks to all of them at this place!

    Now lets continue with a list of features in the next paragraph!

    Features:
    Main Features:
    - Based on latest A13 kernel sources from Google, Kernel is made for Android 13
    - Linux-Stable-Upstream included to 5.10.157
    - Compiled with prebuilt Google clang 16.0.1
    - Backport entire RCU subsystem to Linux 6.0
    - Lazy RCU which should result in power-savings while the device is lightly-loaded or idling, more information here
    - FHD Support for Pixel 6 Pro (display is able to run at 1080p), more info here and here
    - merged kernel/common (improvements to android-common-kernel straight from google)
    - MM subsystem reworked (more info and some patchsets linked in this post)
    - Multi-gen LRU backported/reworked and enabled (more info here, here as well and here) to improve mm and reduce cpu cycles, latest V15 state
    - Utilize an additional kswapd thread to increase throughput for memory reclaim
    - pelt multiplier tied into powerhal to speed up scheduler during interaction (more info here)
    - prevent frequency spikes caused by small transient tasks when the device is idle(more info here)
    - tie mechanism to prevent frequency spikes caused by small tasks also into powerhal
    - scheduler improvements for RT (realtime) tasks
    - introduce and setup PMU limiter (prevents CPU from spiking to max when it isn´t needed, based on PMU reads, more information here)
    - improve camera performance by tuning the powerhal during recording
    - bias tasks of rt, sf and ta groups to prefer high capacity cpus during app launches, interactions
    - improve app launches via powerhal
    - improve trusty driver performance which connects to fingerprintscanner-hal by using high perf wq during fp unlock
    - restrict maximum CPU-Freqs during screen off/ idle to 1.1GHZ for all clusters to save power
    - introduce unfair f2fs rwsems to prevent writer starvation and improve IO perf under heavy load
    - fuse: give wakeup hints to scheduler to speed up compress/decompress in internal storage (details)
    - enable RCU_BOOST (details here), also fix RCU_BOOST behaviour
    - F2FS-Stable updated
    - TCP backports from mainline
    - SSG IO scheduler for reduced overhead and less CPU cycles (more lightweight and android optimized)
    - Scheduler updates from linux-main
    - use improved energy model for exynos cpu cooling/thermal control
    - allow GPU to scale down to 150mhz, but boost to higher value in case of interaction via powerhal
    - affine IRQS to CPU 7 during camera usage for improved performance as it tends to overload the little cores
    - use bbr as default TCP congestion algorithm (fasted algo according to this excellent research from @kdrag0n found here )
    - include bbrv2 from google, more info here
    - Enable support for TTL spoofing
    - Include LRNG, see here and here for more info, bump to v45 with 3.0.0
    - important patches from kernel/common for 5.10 (here are more details)
    - CleanSlate Features from @tbalden, big applause here! (s2s, notification booster, battery saver, flashlight notifications. Please note: cleanslate features that work otherwise with rooted devices like kadaway (adblocking) are not implemented on this kernel since I´m running rooted)
    - dirty pipe exploit fixed
    - supports direct usb access for hi-res playback over USB-C DACs
    - flashing the kernel will preserve root

    Various Optimizations:
    - update several drivers to use power efficient workingqueues (for example wlan driver)
    - kernfs: use buffer from the stack space
    - printk: use buffer from the stack space
    - kthread: use buffer from the stack space
    - bpf: avoid dynamic memory allocation for small value buffers
    - binder: Reserve caches for small, high-frequency memory allocations
    - kernfs: use kmem_cache pool for struct kernfs_open_node/file
    - cgroup: use kmem_cache pool for struct cgrp_cset_link
    - f2fs: reduce timeout for uncongestion
    - f2fs: Demote GC thread to idle scheduler class
    - f2fs: set ioprio of GC kthread to idle
    - mm: vmstat: use power efficient workingqueues
    Wakelock Blocker:
    - advanced wakelock blocker with the ability to block any wakelocks (dangerous, use with caution)
    - please read [URL="https://arstechnica.com/gadgets/2018/08/p-is-for-power-how-google-tests-tracks-and-improves-android-battery-life/"]this for further info

    AK3 Helper Module:
    - restrict little cluster to 1,19ghz mid cluster to 1,19ghz and big cluster to 1,1ghz during screen off, to reduce battery usage for example during music playback
    - only use little cores during screen off/device suspend
    - tie pelt multiplier into the powerhal (more info here)
    - prevent frequency spikes caused by small transient tasks during idle operation (more info here)
    - boost scheduler using the pelt multiplier during fingerprint unlock operation
    - setup and control PMU limiter via powerhal (more info here)
    - dynamically adjust target load for memory interface during interaction

    DOWNLOAD:
    Download is always located in this folder:
    4.2.0, 4.3.0 and 4.4.0 are attached to the release posts linked below as AFH is wonky at the moment.


    Changelog:
    Android 12.0.0

    1.0.0 Initial Release
    1.0.2 https://forum.xda-developers.com/t/...r-pixel-6-pro-aka-raven.4358435/post-85910621
    1.0.5 https://forum.xda-developers.com/t/...r-pixel-6-pro-aka-raven.4358435/post-85924419
    1.3.0 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-85976139
    1.4.0 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-86109665
    1.5.0 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-86259863
    1.7.0 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-86390563
    1.8.4 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-86541727

    Android 12.1.0 Stable (March feature drop and more recent)
    2.0.0 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-86617873
    2.0.1 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-86637233
    2.1.0 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-86695911
    2.3.0 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-86821331
    2.4.0 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-86834981

    Android 12.1.0 Stable (June feature drop and more recent)
    3.0.0 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-86992705
    3.0.1 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-86996237
    3.0.17 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-87127695

    Android 13.0.0 Stable (not QPR beta!)
    4.1.0 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-87290247
    4.1.6 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-87399635
    4.2.0 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-87524609
    4.3.0 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-87697425
    4.4.0 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-87823333



    Android 12L QPR Beta - Deprecated

    Requirements

    - the kernel is made for the stock firmware provided by Google, pay attention to flash a kernel release matching the firmware (flashing on custom roms might work, but you may need workarounds!)
    - unlocked Bootloader
    - USB-Debugging in developer options enabled
    - latest adb and fastboot binaries
    - working adb and fastboot environment so you can flash back to stock in case something goes wrong
    - working magisk environment (a device rooted with latest magisk stable in case you want to be absolutely safe)
    - IMPORTANT: Unrelated to the kernel, but update both slots of your phone to A13! (take a look here)


    How to flash the Kernel:
    1a. Make sure you tick all the requirements above
    1. Download the correct kernel.zip depending on your device (Pixel 6 = oriole || Pixel 6 Pro = raven)
    2. Flash the correct kernel.zip via EXKM, FKM or kernel flasher. Root will be preserved. The AK3 magisk helper module will be automatically installed during flashing the kernel.zip and be present on next reboot.
    Do not remove or disable the AK3 Magisk Helper Module otherwise the device will bootloop.
    3. Reboot and profit.


    Manual installation is no longer supported starting with release 3.0.0, as there´s a free open-source option to flash kernel.zips now.
    Instead use the free kernel flasher, which can be found here.

    Manual installation without relying on paid apps like fkm/exkm:
    Please have a look at the linked post.



    Donations:
    Donations are not mandatory but very welcome if you want to support development or just buy me a coffee/tea/beer :)
    If you like my work: http://paypal.me/freak07

    Credits:
    @osm0sis for all his work on AK3.
    @tbalden for being the best HTC, Pixel, OnePlus and Asus wingman!
    @capntrips for all his work on the pixel 6!
    @LeeDroid and @mwilky for their awesome roms and work I used on multiple devices!
    @Captain_Throwback for all the mentoring and guidance!
    @Eliminater74 for bringing me into the game and the Inspiration
    @nathanchance for his upstream guidance and assistance
    @RenderBroken for helping me out
    @flar2 for all his work
    @joshuous for all the help he provided to me in the past!
    @arter97 for giving me advice
    @kdrag0n for his help and advices!
    @topjohnwu for magisk and his entire work!


    Source Code: https://github.com/freak07
    44
    Update to 4.1.0

    Hey guys and girls,

    I hope everyone started into a good week. Here´s the next release. It´s for stable Android 13.
    Thanks to Google releasing the kernel source for the previews and the betas I´m able to push this update out very quickly. As in the past, the code didn´t change between last beta and stable release.

    There are again a lot of changes in this release. I´ll try to keep the release post short as I don´t have that much time lately.


    FHD/1080P Support for Pixel 6 Pro

    The biggest change is FHD support for the Pixel 6 Pro. If you follow twitter you might have seen this tweet from @MishaalRahman.
    Instead of using the display driver that´s supposedly for the Pixel 7 Pro, FHD support was added to the Pixel 6 Pro display driver. There were a few obstacles to make it run properly on the Pixel 6 Pro, but I got it working nicely so far. If anyone has more experience than me regarding panel timings, display drivers etc, feel free to push any improvement as a pull request to my github or point me towards any improvement.

    As a result you can now select 1080p resolution from settings after flashing the kernel. Dynamic refresh rate works, brightness scaling works, no tints, colour shifts or contrast issues either. AOD has a 1080p Low-Power timing as well.

    You´ll find a few more infos with a short video on my tweet here:
    Screenshot_20220816-083147.png
    Screenshot_20220816-083204.png

    It´s perfectly usable on a daily basis so far. I ran it for a few days without issues on my end. While the advantage might be debatable (saving battery, less load on GPU, still needing to drive the same amount of pixels in the end even on lower resolution, etc etc) having options is nice and this is why I decided to ship it.

    Apps need to redraw after switching resolution, sometimes 1080p on big display size selected in settings the UI looks a bit sketchy. So I think Google is still working on that.

    There´s however one bug I found so far that makes me believe this is still very much a WIP from google. If having the "show current refresh rate" option from dev settings enabled while switching resolutions, the display will black out and a restart needs to be forced by keeping the power button pressed or using adb interface to restart the phone. This is not due to the kernel, but display settings in framework getting scrambled as it´s not yet implemented 100% on googles end. So be warned. :)


    MM Subsystem Rework

    MM subsystem was completely reworked including many improvements from linux-mainline. During this MGLRU was also reworked a bit and works better now. I´ll include links to a few of the improvements/patchsets in hide-tags below, if you´re interested beyond that please check out my github.
    links:

    Additionally tie in a few of the MM changes into the powerhal. For example Proactive compaction is more aggressive during screen-off/device suspended operations to improve long term-performance.

    Other changes:

    Also tune the powerhal and implement all A13 changes, according to the changes that were already present on A12.

    Latest changes from f2fs-stable are included, which include several bugfixes and small improvements.
    Binder improvments/fixes, scheduler improvements from kernel/common, performance for exfat formatted storage device improved (niche use case, but still nice) and other little improvements.
    For other changes and details please take a look at github.


    I wish everyone a nice day.

    If you´re one of the unfortunate ones that suffer from the device is corrupt bug on pixel 6 series please take a look at the FAQ at the beginning of this thread it contains a solution. The issue is probably caused by a bug that affects pixel 6 devices and has nothing to do with magisk or a kernel, it just happens to get triggered when using any of those.



    Changelog:

    - Rebase kernel fully on A13 trees
    - Linux-Stable bumped to 5.10.136
    - FHD/1080p support for Pixel 6 Pro
    - all previous features and improvements kept intact
    - bump f2fs-stable to latest available
    - rework mm subsystem (check git for more details)
    - scheduler improvements
    - binder improvements from kernel/common
    - improve exfat performance (if someones uses exfat formatted devices)
    - loads of other changes from kernel/common
    - update powerhal to account for a13 changes and port existing changes over
    - loads of other changes, please check github



    Download:


    If you´re coming from another kernel restore stock boot.img, dtbo.img, vendor_boot.img and vendor_dlkm.img before flashing. Thank you.

    I wish everybody a great day/evening!
    Have fun, enjoy the kernel and your phone.



    If you like my work please consider a donation.
    Donations are not mandatory but very welcome.
    If you like my work and want to buy me a coffee/green tea: http://paypal.me/freak07
    43
    Update to 4.2.0

    Hey guys and girls,

    I hope everyone started well in the new week. Here´s the next release and it´s a rather big one with lots of under the hood improvements.
    We already had all the changes in from the October security patch release released, due to merging linux-stable stable and kernel/common in advance.
    The kernel is now at 5.10.146 way ahead of the stock kernel. To further emphasize the importance of this. About 90% of kernel security issues are solved in linux stable. While I didn´t check the actual number myself, I´d have estimated about the same (80-90%) before actually reading the slides from @arter97 presentation.
    What also needs to be kept in mind is that a big part of those security issues are resolved in linux-stable sometimes months ago before those patches end up in a monthly security patch. Additionally to that the security patches are about 3 months behind the discovery of those vulnerabilities.

    Amongst linux-stable upstream there are a few other not minor updates in this kernel.

    Clang
    The kernel is now compiled with the latest prebuilt Clang from Google. This was quite a journey as this is a pretty big update to clang. This is quite experimental to be on googles side of a "bleeding" edge compiler, but after fixing several issues that originated from the new compiler it ran stable for over 2 weeks.

    There´s a potential for CFI failures that originates from that new Clang rather than a "real attack", due to the changes in clang.
    Short reminder what CFI actually does: Control flow integrity (CFI) is a security mechanism that disallows changes to the original control flow graph of a compiled binary, making it significantly harder to perform such attacks.
    A typical crash (that´s not wanted and originates from compiler changes rather than an actual attack, which is already resolved of course ) would look like the following: Open camera app, due to compiler changes CFI is accidentally tripped every time this code is executed.
    I think we catched all of these newly CFI failures and everything is nice and stable. In case you discover such a behaviour please send me the contents of sys/fs/pstore, once the phone booted back up.

    There´s always the possibility of a "real" attack in which CFI will crash the phone, before the attacker can compromise the phone. That´s why keeping subsystems updated is important.


    Powerhal
    The powerhal was retuned due to changes to the scheduler introduced. It should work even better now, regarding efficiency and performance. Of course I try to tune it also to my personal needs, while trying to keep it working for all workloads. The changes are not drastic, so please don´t post after several hours you see drastic differences.

    Other improvements
    Several other improvements from kernel/common (for higher branches than 5.10) and linux-main were backported to this branch so we can benefit from those improvements. For details please check my git.



    I´d like to write all of this with more detail, but at the moment I lack the time to do so.

    Kernel is compiled for stable A13, not A13 QPR Beta!


    I wish everyone a nice day.

    If you´re one of the unfortunate ones that suffer from the device is corrupt bug on pixel 6 series please take a look at the FAQ at the beginning of this thread it contains a solution. The issue is probably caused by a bug that affects pixel 6 devices and has nothing to do with magisk or a kernel, it just happens to get triggered when using any of those.



    Changelog:

    - Linux-Stable bumped to 5.10.146
    - kernel is compiled with latest prebuilt google clang 15.0.2
    - improvements from linux-mainline
    • locking subsystem
    • memory management
    • more details please check github
    - patches to f2fs
    - updates from kernel/common to several subsystems
    - tweak powerhal for improved performance/efficiency


    Download:
    Attached to release post as AFH is currently down.
    I´ll push to AFH once it´s back up.



    If you´re coming from another kernel restore stock boot.img, dtbo.img, vendor_boot.img and vendor_dlkm.img before flashing. Thank you.

    I wish everybody a great day/evening!
    Have fun, enjoy the kernel and your phone.



    If you like my work please consider a donation.
    Donations are not mandatory but very welcome.
    If you like my work and want to buy me a coffee/green tea: http://paypal.me/freak07
    37
    Update to 1.8.4

    Hey guys and girls,


    So here´s the next update. It´s kind of an off schedule update, as I planned to update the kernel with the next security update/feature drop.

    But in the light of recent events regarding the new exploit called "Dirty Pipe" (more info here), which is similar to the "Dirty Cow" exploit from a while ago, but easier to exploit this time, I decided to release an update ahead of schedule.

    This exploit was fixed in linux-stable 5.10.102, as opposed to a single commit in AKC (android kernel common, commit here). This shows once more why merging linux-stable is beneficial as explained in detail in the OP.

    Since one of the key aspects of this kernel is security and staying on par with upstream (which often fixes exploits way ahead of android security bulletin updates, even before an exploit is even known or fixed via a patch on the security bulletin) I decided to release this update as quickly as possible, so this exploit is fixed on devices running this kernel.

    Several other notable improvements and changes in this release:
    Bring in scheduler updates from Android 13 Developer Preview, which aim at improving task placement. (adjust powerhal accordingly)
    BFQ IO-Sched is now on par with linux-mainline.
    Several fixes to mm subsystem, f2fs and others.

    Several other improvements are included as well. More details in the changelog.
    Download is below.
    Updated instructions in the OP!


    Changelog:
    - linux-stable 5.10.103
    - contains fix for the dirty pipe exploit
    - built with clang 14.0.2 prebuilt by google
    - improvments from kernel/common
    - fix memory leaks
    - security related patches
    - mm improvments
    - f2fs fixes
    - scheduler fixes
    - for details please check github
    - built with improvements from A13 Dev Preview to display driver
    - other changes please look at my github


    Download:


    Instructions can be found in the OP! Please follow the instructions to avoid any issues.
    If you´re coming from another kernel restore stock boot.img, dtbo.img, vendor_boot.img and vendor_dlkm.img before flashing. Thank you.
    37
    Update to 1.7.0

    Hey guys and girls,


    So here´s the next update. It includes the february security update. Most of the changes brought by the February kernel source drop, were already included in this kernel by merging kernel/common and linux-stable.


    Several other notable improvements and changes in this release:
    Improve f2fs performance by merging a patchset to prevent writer starvation for the checkpoint thread. This was discussed this month in the f2fs mailing list and is already merged to the kernel/common tree. It´ll improve performance under heavy I/O utilization.
    You can find more information following the discussion here.
    Necessary backports were brought to the kernel and the platform specific f2fs-implementation was also adjusted.
    Latest f2fs-stable was also merged to the kernel.

    Update the patchset to prevent frequency spikes caused by small tasks as well. Tie those new changes into the powerhal. (That means users not flashing the kernel.zip, but instead use the manual installation method, which are only a handful from the download count, need to flash the updated magisk helper module. Users that flash the kernel.zip via FKM/EXKM have to just flash and forget)

    Several other improvements are included as well. More details in the changelog.
    Download is below.
    Updated instructions in the OP!


    Changelog:
    - February Security update merged
    - linux-stable 5.10.96
    - include latest f2fs-stable
    - improvments from kernel/common
    - fix memory leaks
    - security related patches
    - mm improvments
    - for details please check github
    - introduce unfair f2fs rwsems to prevent writer starvation and improve IO perf
    - update patchset to prevent freq spikes caused by small transient tasks (also tie this into powerhal)
    - give pelt multiplier power hint for scheduler performance boost during fingerprint unlock
    - fuse: give wakeup hints to scheduler to speed up compress/decompress in internal storage (details)
    - enable RCU_BOOST (details here), also fix RCU_BOOST behaviour
    - update LRNG implementation (thanks to arter97 )
    - improvements/fixes for CleanSlate features
    - other changes please look at my github


    Download:


    Instructions can be found in the OP! Please follow the instructions to avoid any issues.
    If you´re coming from another kernel restore stock boot.img, dtbo.img, vendor_boot.img and vendor_dlkm.img before flashing. Thank you.