Development [Kernel][08.06.2022][Android 12.1.0]Kirisakura 3.0.1 for Pixel 6/Pro aka "RAVIOLE"

[Utini]

Flashed fine over 2.1.0

While I cannot comment on battery life (yet) it feels like the phone is much smoother now.

Maybe the reboot (and an SD Maid run) have made it smoother. No idea if that does anything to performance.
But I did that together with flashing the new update.

 

[cabagekiller]

I want to add the latest kernel has helped my battery life a ton. And I wanted to thank you for your work. !

 

[Jon8RFC]

I guess everyone else already tried going into recovery and trying to get /proc/last_kmsg (doesn't exist) and /sys/fs/pstore (doesn't exist), or similar. I just googled and came across those...although last_kmsg was from 2012 and may not be applicable.

Anyway, I read that "you should patch your boot.img on your own phone" to play it extra safe. This has me wonder if maybe there is something barely different about the boot.img files from one phone to the next. Is there a chance, at all?
If so...
Freak07, would you mind sending me your working Kirisakura_Raven-2.1.0_A12_stable 24306 manually patched boot.img for raven/pixel6pro, if that's your phone? If it's a worthwhile trial, I'd like to see (just for grins), what happens if we trade. I never patched 2.3.0 with 24306, so I don't have that one handy, but I could still try your 2.3.0 anyway.

If feel like there must be a way to narrow down the cause, whether it's magisk or the phone, because of whatever changed between 24302 and 24303 being able to point at something in particular.

EDIT:
Actually, I do see /sys/fs/pstore/console-ramoops-0 with su while I'm booted into android. But apparently I don't know the right way to access that from recovery.

adb shell was my missing step. So /sys/fs/pstore/ does exist, but it's empty. No console-ramoops-0 either. Does this kernel support config_pstore?

 

[viper8u2]

I agree, my phone has been off the charger for almost 24 hours screen on time says 6h 27m and I am 53% battery left. Wow I just sent you a small donation to your Paypal to show my appreciation. Thank you

 

[roirraW "edor" ehT]

Anyway, I read that "you should patch your boot.img on your own phone" to play it extra safe. This has me wonder if maybe there is something barely different about the boot.img files from one phone to the next. Is there a chance, at all?

There is definitely no difference in the boot.img on different devices before patching with Magisk. There is definitely a difference in the boot.img when patched with Magisk on different devices.

 

[Jon8RFC]

There is definitely no difference in the boot.img on different devices before patching with Magisk. There is definitely a difference in the boot.img when patched with Magisk on different devices.

Just to clarify that we're on the same page...

It's not merely a difference in the hash of the file because maybe magisk salts something innocuous but unique into each patched boot.img, like the wifi mac address and the first and last 2 digits of the IMEI or something?

So if I buy two Pixel 6 Pro phones, set them up identically, then patch boot.img, they will be fundamentally different and the boot.img files will function differently? If so, I'm even more interested to try a "working" 24306 boot.img

 

[capntrips]

Just to clarify that we're on the same page...

It's not merely a difference in the hash of the file because maybe magisk salts something innocuous but unique into each patched boot.img, like the wifi mac address and the first and last 2 digits of the IMEI or something?

So if I buy two Pixel 6 Pro phones, set them up identically, then patch boot.img, they will be fundamentally different and the boot.img files will function differently? If so, I'm even more interested to try a "working" 24306 boot.img

For what it's worth, if I patch the same boot image with the same version of Magisk on both a Pixel 6 and a Pixel 5a, the binaries are identical. I'm sure there are some configuration differences between some devices that would prevent that from being the case, so I wouldn't expect that to be true for all devices.

 

[Freak07]

I guess everyone else already tried going into recovery and trying to get /proc/last_kmsg (doesn't exist) and /sys/fs/pstore (doesn't exist), or similar. I just googled and came across those...although last_kmsg was from 2012 and may not be applicable.

Anyway, I read that "you should patch your boot.img on your own phone" to play it extra safe. This has me wonder if maybe there is something barely different about the boot.img files from one phone to the next. Is there a chance, at all?
If so...
Freak07, would you mind sending me your working Kirisakura_Raven-2.1.0_A12_stable 24306 manually patched boot.img for raven/pixel6pro, if that's your phone? If it's a worthwhile trial, I'd like to see (just for grins), what happens if we trade. I never patched 2.3.0 with 24306, so I don't have that one handy, but I could still try your 2.3.0 anyway.

If feel like there must be a way to narrow down the cause, whether it's magisk or the phone, because of whatever changed between 24302 and 24303 being able to point at something in particular.

EDIT:
Actually, I do see /sys/fs/pstore/console-ramoops-0 with su while I'm booted into android. But apparently I don't know the right way to access that from recovery.

adb shell was my missing step. So /sys/fs/pstore/ does exist, but it's empty. No console-ramoops-0 either. Does this kernel support config_pstore?

Just to clarify that we're on the same page...

It's not merely a difference in the hash of the file because maybe magisk salts something innocuous but unique into each patched boot.img, like the wifi mac address and the first and last 2 digits of the IMEI or something?

So if I buy two Pixel 6 Pro phones, set them up identically, then patch boot.img, they will be fundamentally different and the boot.img files will function differently? If so, I'm even more interested to try a "working" 24306 boot.img

For what it's worth, if I patch the same boot image with the same version of Magisk on both a Pixel 6 and a Pixel 5a, the binaries are identical. I'm sure there are some configuration differences between some devices that would prevent that from being the case, so I wouldn't expect that to be true for all devices.

Correct, you should always patch the boot.img yourself on your own device. Besides the advice to do that as patching on different devices might not create the exact same binary (has happened in the past, but don´t ask my why), the uninstall magisk option will not work properly if not patched on your own device. That´s the most important reason.

Kernel has pstore support. You can check how to get a ramoops via the linked post in the FAQ.
As far as I´m aware you can´t access pstore from stock recovery. we´d need a custom recovery for that.
You already learned how to access it from the running system, once booted up again after a crash occured.

Attached is the pixel 6 pro/raven boot.img uploaded to androidfilehost for 2.3.0 patched via magisk 24306.
Flashed powerhint module via magisk manager, then flashed the 4 images according to the instructions via fastboot/fastbootd and booted up no problems.

I agree, my phone has been off the charger for almost 24 hours screen on time says 6h 27m and I am 53% battery left. Wow I just sent you a small donation to your Paypal to show my appreciation. Thank you

Glad it´s working out for you!
Thank you very much for the donation! It´s greatly appreciated

 

[Freak07]

Update to 2.3.0

Hey guys and girls,

Here´s a small update for the original 2.3.0 update. The only changes are done to the scripts that setup the device during boot and a small adjustment to the powerhal to better integrate the PMU limit feature.

If you flashed the kernel.zip via a kernel manager app:
Re-Uploaded 2.3.0 to androidfilehost. Just redownload and reflash the zip and you´re good to go.


user following the manual installation method:
just download the new powerhint module and flash via magisk manager if you´re already running 2.3.0. Otherwise follow the instructions.



Previous changelog included for reference.

Alright here´s the next update. It´s a major one. I want to put it out shortly before we hopefully receive the next monthly security update on Monday kinda as a final rehearsal.
This kernel is made for stable Android 12.1.0 April firmware. Not QPR Beta or A13 Beta!
Once I find enough time or QPR beta gets updated, I might update the QPR beta release. No plans to support A13 beta.

A few changes from A13 Beta are merged to the kernel so we can enjoy the improvements on A12 already. Most of them aim to improve the scheduler and task placement.
A13 Beta source contains a commit that can restrict max-cpufreqs based on PMU reading. I setup this mechanism to mildly cut back max-freqs when they aren´t needed. It works quite well so far, with no performance impacts during scenarios where max cpufreq is beneficial. (e.g. app launching, camera launching etc)
Tasks of rt, sf and ta groups are now biased to start on high capacity CPUs during app launches, interactions etc.
As usual, depending on your usage you may or may not notice a difference during these scenarios.

While tracing I noticed kswapd often takes 100% cpu share when reclamation is happening. Since we use an 8 core cpu, an additional kswapd thread is being spawned during boot, which increases throughput for kswapd in these scenarios.

DAMON patch-series is included to this release as it was merged to kernel/common. It includes DAMON-reclaim. You can read more about it here.
This feature is currently disabled by default on this kernel. If you want to use it you can tune it to your liking as per the documentation linked above.
The feature can be enabled via:

echo 1 > /sys/module/damon_reclaim/parameters/enabled

I think Google might start to use it in the not so far future, but for now it´s disabled by default.


Disclaimer:
I´ll keep the warning as to preferably using magisk stable to avoid potential issues as well here in this post.
Please note that 24306 works fine for me though on non beta, stable April firmware!
Important:
Make sure you´re being rooted with magisk 24300 stable before flashing the kernel if you´re unsure. Any magisk version above 24303 might potentially lead to a reboot back to bootloader since android 12.1.0 and A12L QPR3 Beta. At the moment this only affects canary, but I put the warning just in case this will not get resolved in upstream magisk in time until the next stable drops. I saw a post that some modules also have problems with latest canary, so there´s a lot going on at magisk´s side at the moment.
A post containing a short write-up how to "downgrade" magisk can be found following this link.

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 merged to 5.10.113
- Use prebuilt Google Clang 14.0.5 for compilation
- Utilize an additional kswapd thread to increase throughput for memory reclaim
- improvements from kernel-common a13 to page_pinner
- mainline backports for BFQ scheduler
- rework Multi-Gen LRU implementation
- merge DAMON to the kernel, which includes DAMON-Reclaim (this feature is not enabled by default, you need to enable it manually if you want to test)
- scheduler improvements for RT (realtime) tasks
- other scheduler improvements
- include scheduler improvements from A13 Beta regarding better task placement
- introduce and setup PMU limiter (prevents CPU from spiking to max when it isn´t needed, based on PMU reads)
- bias tasks of rt, sf and ta groups to prefer high capacity cpus during app launches, interactions, camera launches, etc



Download:

Downloads for : -Android- Generic Device/Other | AndroidFileHost.com | Download GApps, Roms, Kernels, Themes, Firmware and more. Free file hosting for all Android developers.

Download GApps, Roms, Kernels, Themes, Firmware, and more. Free file hosting for all Android developers.

www.androidfilehost.com

Instructions can be found in the OP! Please follow the instructions to avoid any issues and read this post carefully. Don´t use magisk canary 24303 or more recent to avoid potential 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.

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

 

[Jon8RFC]

Kernel has pstore support. You can check how to get a ramoops via the linked post in the FAQ.
As far as I´m aware you can´t access pstore from stock recovery. we´d need a custom recovery for that.
You already learned how to access it from the running system, once booted up again after a crash occured.

Attached is the pixel 6 pro/raven boot.img uploaded to androidfilehost for 2.3.0 patched via magisk 24306.
Flashed powerhint module via magisk manager, then flashed the 4 images according to the instructions via fastboot/fastbootd and booted up no problems.

Thanks! Unfortunately, it didn't work.

I removed my PIN hoping maybe if the pstore contents were encrypted-hidden in recovery (whatever that weirdness is that it does) that it'd be accessible, but it wasn't. I remember TWRP being unique in asking for the PIN to be able to access data from the phone.

As best I can infer, the pstore folder is overwritten on boot. I compared the files after a boot, then rebooted, and none of the old data was retained upon reboot. I also let it bootloop on the 5.10.113 kernel for ten times, then I flashed back to the 5.10.109 kernel, grabbed the console-ramoops-0 file and it only contained 5.10.109 references.

There were some older files I grabbed, but after seeing that data is overwritten on reboot, I struggle to believe that the data is relevant, which is why I tried with a different version kernel to more easily check. I've attached files I grabbed after clicking through a bootloop 10 times, then letting it idle through a bootloop 10 times, consecutively, then flashing a working boot.img. Based on the file size being half of that of a reboot from a successful boot (which overwrote all of the old data), I don't know if those "reboot info" messages were just from my flashing reboots in my batch file, or what.

Thanks again for entertaining this mess, Freak07. I really wish there was a quick way to figure this out...or that TWRP existed so I could actually pull the files in confidence.

 

[Freak07]

Thanks! Unfortunately, it didn't work.

I removed my PIN hoping maybe if the pstore contents were encrypted-hidden in recovery (whatever that weirdness is that it does) that it'd be accessible, but it wasn't. I remember TWRP being unique in asking for the PIN to be able to access data from the phone.

As best I can infer, the pstore folder is overwritten on boot. I compared the files after a boot, then rebooted, and none of the old data was retained upon reboot. I also let it bootloop on the 5.10.113 kernel for ten times, then I flashed back to the 5.10.109 kernel, grabbed the console-ramoops-0 file and it only contained 5.10.109 references.

There were some older files I grabbed, but after seeing that data is overwritten on reboot, I struggle to believe that the data is relevant, which is why I tried with a different version kernel to more easily check. I've attached files I grabbed after clicking through a bootloop 10 times, then letting it idle through a bootloop 10 times, consecutively, then flashing a working boot.img. Based on the file size being half of that of a reboot from a successful boot (which overwrote all of the old data), I don't know if those "reboot info" messages were just from my flashing reboots in my batch file, or what.

Thanks again for entertaining this mess, Freak07. I really wish there was a quick way to figure this out...or that TWRP existed so I could actually pull the files in confidence.

Like I said you can´t access pstore in stock recovery.

On each reboot sys/fs/pstore will be overwritten from the past running session. If you boot from fastboot to fastbootd to flash vendor_dlkm, the files will be overwritten as that´s a reboot.
Might need to use a few tricks to get a ramoops then.

I don´t fully understand what you´re trying to do or get logs for. From your previous post I assume you´re trying to figure out why patching with magisk 24300 works and boots but patching with magisk 24306 doesn´t work on your end?

If your device is bootlooping and not crashing like you describe, you can simply try to get a dmesg via adb shell with su access granted. If you get to adb shell there´s no need for a pstore.

adb shell

su

dmesg -w

check what´s happening or save the log.


So how you can get pstore for your situation if it´s crashing and not bootlooping and you never get to adb shell:

Install latest powerhint module via magisk manager.
Flash 2.3.0 boot.img patched via magisk 24300, the other images according to instructions and make sure everything works.
Now flash 2.3.0 boot.img patched via magisk 24306 and let the phone crash.
You might need to get the timing right if you press any buttons to get to bootloader. If you press too long you trigger a reboot which will overwrite previous pstore.

Once in bootloader, flash back working 24300 magisk patched 2.3.0 image. boot up and check if you have a ramoops of the crash. That way you avoid rebooting to fastbootd.

The 4 images you´re flashing always have to match from the same compilation. you can´t mix and match there.

 

[Jon8RFC]

Like I said you can´t access pstore in stock recovery.

On each reboot sys/fs/pstore will be overwritten from the past running session. If you boot from fastboot to fastbootd to flash vendor_dlkm, the files will be overwritten as that´s a reboot.
Might need to use a few tricks to get a ramoops then.

I don´t fully understand what you´re trying to do or get logs for. From your previous post I assume you´re trying to figure out why patching with magisk 24300 works and boots but patching with magisk 24306 doesn´t work on your end?

If your device is bootlooping and not crashing like you describe, you can simply try to get a dmesg via adb shell with su access granted. If you get to adb shell there´s no need for a pstore.

adb shell

su

dmesg -w

check what´s happening or save the log.


So how you can get pstore for your situation if it´s crashing and not bootlooping and you never get to adb shell:

Install latest powerhint module via magisk manager.
Flash 2.3.0 boot.img patched via magisk 24300, the other images according to instructions and make sure everything works.
Now flash 2.3.0 boot.img patched via magisk 24306 and let the phone crash.
You might need to get the timing right if you press any buttons to get to bootloader. If you press too long you trigger a reboot which will overwrite previous pstore.

Once in bootloader, flash back working 24300 magisk patched 2.3.0 image. boot up and check if you have a ramoops of the crash. That way you avoid rebooting to fastbootd.

The 4 images you´re flashing always have to match from the same compilation. you can´t mix and match there.

Thanks. What it's doing is crashing then, and it cyclically reboots itself.

I was doing that before, but I expected something to stand out to me more obviously than some of these things which look like normal unlocked bootloader or custom kernel kind of things. I hope that the AVB error is exactly what it is, and then it's a piece of cake fix for magisk to correct. Is that it, a bug in magisk? Do I just post a bug report and send them dtbo.img, vendor_boot.img, vendor_dlkm.img, and both 24300 and 24306 boot.img files? Nope, that looks normal for unlocked bootloader/custom kernel stuff. And I have no idea what the other errors could remotely mean, so I hope you have some insight.

1. successful boot with Kirisakura 2.1.0 patched via magisk 24300 and powerhint_p6_v11.zip
2. restarted via interface
3. held volume down button only after power off, bootloader came up
4. fastboot flash boot kirisakura_2.1.0_magisk_patched-24306_pixel6_apr22.img
5. clicked power button once to issue "START" from bootloader
6. phone rebooted
7. allowed to crash
8. when screen was blank, held volume down button, bootloader came up
9. fastboot flash boot kirisakura_2.1.0_magisk_patched-24300_pixel6_apr22.img
10. clicked power button once to issue "START" from bootloader
11. phone rebooted
12. copied sys/fs/pstore/console-ramoops-0 file

 

[Freak07]

Thanks. What it's doing is crashing then, and it cyclically reboots itself.

I was doing that before, but I expected something to stand out to me more obviously than some of these things which look like normal unlocked bootloader or custom kernel kind of things. I hope that the AVB error is exactly what it is, and then it's a piece of cake fix for magisk to correct. Is that it, a bug in magisk? Do I just post a bug report and send them dtbo.img, vendor_boot.img, vendor_dlkm.img, and both 24300 and 24306 boot.img files? Nope, that looks normal for unlocked bootloader/custom kernel stuff. And I have no idea what the other errors could remotely mean, so I hope you have some insight.

1. successful boot with Kirisakura 2.1.0 patched via magisk 24300 and powerhint_p6_v11.zip
2. restarted via interface
3. held volume down button only after power off, bootloader came up
4. fastboot flash boot kirisakura_2.1.0_magisk_patched-24306_pixel6_apr22.img
5. clicked power button once to issue "START" from bootloader
6. phone rebooted
7. allowed to crash
8. when screen was blank, held volume down button, bootloader came up
9. fastboot flash boot kirisakura_2.1.0_magisk_patched-24300_pixel6_apr22.img
10. clicked power button once to issue "START" from bootloader
11. phone rebooted
12. copied sys/fs/pstore/console-ramoops-0 file

Yes that looks like you catched it.

I´d open an issue on magisk github. Explain that boot.img patched via magisk 24300 works, while 24306 breaks booting.
Upload all images (boot, dtbo, vendor_boot and vendor_dlkm), the unpatched ones and both patched images.
Describe the setup of your phone, verity enabled, remove all other modifications etc except the powerhint module to make sure the issue is not from something else.

Include the ramoops file and maybe someone might know why that is happening.

 

[f8lxninja]

Successfully flashed 2.3.0 on ProtonAOSP 12.3.1 test 1 for patrons, will see if I encounter any problems.

 

[XSLdesire]

hello, can't we disable the magisk module that comes with this kernel? I did that then got stuck at boot logo

 

[Freak07]

hello, can't we disable the magisk module that comes with this kernel? I did that then stuck at boot logo

No you can't disable it. It's crucial as it contains a part of the updated firmware from the qpr beta, which some kernel changes rely on.

I'll put a warning in the instructions in the OP.

 

[XSLdesire]

No you can't disable it. It's crucial as it contains a part of the updated firmware from the qpr beta, which some kernel changes rely on.

I'll put a warning in the instructions in the OP.

ok, i see. thanks for the reply

 

[McNaccken]

Hi there, just wanted to say big thanks to Freak07 and this awesome kernel! Flashed the latest one without a single problem and so far so good. Will report back in a few days how it goes, especially about the battery usage. Really curious about that. Thanks again!

 

[awarman]

Does anyone notice degraded performance after your phone has been up and running for over 24 hours? I have no idea if it's the Kernel or not. I mostly notice that after a reboot I can record my screen with no fps drops then a day later when I attempt to use it, I notice the fps drops and lag. Is it kernel related or does it happen on stock? Is it just me?

 

[Admiral2145]

Does anyone notice degraded performance after your phone has been up and running for over 24 hours? I have no idea if it's the Kernel or not. I mostly notice that after a reboot I can record my screen with no fps drops then a day later when I attempt to use it, I notice the fps drops and lag. Is it kernel related or does it happen on stock? Is it just me?

It was like that for me on the kernel before this one... I haven't tried this newer version yet to see if it was fixed or not... Most people said it was nothing wrong when I brought it up here.