If it does, going back to stock seemed to fix the reboots for me.Not happening here yet either, but watching carefully. Worried it's incoming, lol.
If it does, going back to stock seemed to fix the reboots for me.Not happening here yet either, but watching carefully. Worried it's incoming, lol.
So that's something that's unrelated to this kernel specifically and actually in the source? Sorry just trying to learn and understand![]()
Forgot to ask this yesterday, you´re not on magisk 25210 are you?Apparently it was something with the actual driver. Freak looked into it earlier today. It was temporary and oddly random it seems. Hasn't happened in awhile.
I'm experiencing the random reboots now too. After phone reboots, I can maybe use if for 1 minute before it reboots. Gonna flash stock kernel to see if it helps.
You´re not on magisk canary 25210 are you? Because this sounds very much like a problem some users faced earlier.If it does, going back to stock seemed to fix the reboots for me.
Same configuration here, no reboots so far.No reboots for me since I flashed on the same day 1.0.0 was released, on the contrary this is much smoother than the previous version and it's been running great, edit: using Magisk stable
Stable magisk 25.2Forgot to ask this yesterday, you´re not on magisk 25210 are you?
I also think you misunderstood, this is an actual kernel problem, as it´s a null pointer that crashes the kernel.
To maybe understand better:
I merge the updates from f2fs-stable regularly to this kernel. f2fs-stable is where development for the f2fs-driver happens and "stable" updates are pushed. This includes for example security fixes, stability fixes, new features, performance improvements for this specific part of the kernel. This code is usually very well tested and rarely contains bugs.
However android is very specific and can introduce certain scenarios that are not tested otherwise.
It seems that one of the commits from the recent updates to f2fs I merged on march 4th or march 11th might be the cause of the null pointer.
The null pointer seems to be happen very rarely (I haven´t faced the issue in nearly 3 weeks and the p7pro is may daily phone) with no actual way to reproduce, which will make testing a potential fix harder.
This is also probably the reason why the bug wasn´t discovered before the commits where pushed to f2fs-stable in the first place.
I´m probably going to revert all of those commits for the time being and pushed a new release until a fix for the null pointer is found.
You´re not on magisk canary 25210 are you? Because this sounds very much like a problem some users faced earlier.
Please share the contents of sys/fs/pstore next time before reverting to stock so I can have a look at what´s happening.
No reboots for me since I flashed on the same day 1.0.0 was released, on the contrary this is much smoother than the previous version and it's been running great, edit: using Magisk stable
all good so far, no reboot, latest stock on magisk delta latest. Even uses the battery saver level 3 with cleanslate app.
yeah I think it´s extremely rare that this panic is triggered, so I guess most of us are completely unaffected. If it would happen regularly no chance I could run on my daily phone for 3 weeks without running into it a single time.
I'm using stable Magisk. I've been avoiding canary builds as they have been causing issues.
Thanks so we can probably rule magisk out this time.
Update to Raviantha 1.0.1
Hey guys and girls,
That´s a hotfix for 1.0.0 and the previous release. The recent update to the f2fs drivers from beginning of March seem to have introduced a null pointer exception that happens very very rarely. Thanks to @JakeDHS07 for providing the logs! I also submitted this to f2fs-stable so hopefully it can be fixed there.
Until a proper fix is found I´m going to revert the tag of f2fs patches that introduced this bug. That´s the only change in 1.0.1.
I´ll include the previous release post with all the information below.
Changelog 1.0.1:
- revert latest f2fs stable patches
Changelog 1.0.0 above:
So here´s the next release for stable March firmware, which is now QPR2.
Aside from that as already hinted at the previous Pixel 7/Pro release for March google kind of unified the main kernel tree for the Pixel 6 and Pixel 7 series. That means I´m now able to compile the release for Pixel 6 and Pixel 7 from the same main kernel tree after some modifications to my own changes! This saves me a bit of time and means all not vendor/firmware/hardware specific improvements added to the kernel are now shared automatically, without me constantly merging them back and forth.
Hence the name change and starting from 1.0.0 again. Pixel 6 Oriole/Pixel 6 Pro Raven combined are Raviole, Pixel 7 Panther/Pixel 7 Pro Cheetah combined are Pantah, so Raviantha is the combination of both Raviole and Pantah.
Improve Uclamp
Improve uclamp patchset and detect capacity inversion. This greatly reduces the few missed frames we had.
Camera Launch Speed
Speed Up Camera launch by quite a bit. Also improve animations around camera compared to stock kernel.
Make sure to update/flash the new powerhint module attached to this post via magisk manager as it´s been updated!
Please note that this release is not for the QPR Beta firmware, but the stable android 13 march firmware!
Please make sure to not use magisk canary 25210. It breaks module loading and causes a lot of issues! Please use either stable magisk or canary 25206.
Latest platform tools have issues flashing super.img, please use platform tools 33.0.3 when updating your firmware to march updae.
There are other small improvements as well. Please check my github for those.
The kernel is made for stable A13 firmware, not beta.
I wish everyone a nice day.
Changelog:
- Linux-Stable bumped to 5.10.175 containing tons of stability and security fixes
- improvements to the scheduler
- improvements to uclamp, prevent capacity inversion (reduce missed frames)
- greatly speed up camera launch time!
- ported improvements from QPR3 beta
- other fixes please check github
Download:
Attached to release post as AFH is currently down.
Make sure to update and keep the powerhint module installed via Magisk Manager!
If you´re coming from another kernel restore stock boot.img, dtbo.img, vendor_kernel_boot.img and vendor_dlkm.img before flashing. Thank you.
Make sure to meet the requirements and read the OP as well as the FAQ before flashing.
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
I attached the powerhint modules to the release post of raviantah 1.0.1 now.sorry, I'm confused.
can we flash this "Raviantha 1.0.1"
over 1.3.0 ?
"Make sure to update/flash the new powerhint module attached to this post"
which powerhint module should we use ?
"Massive" as in benchmarks. Small in non benchmark scenarios, scoped storage eats up those gains for a lot of apps too.The gains from disabling fsync are massive on every device I've owned capable of having it disabled.
Because Android keeps fsync strictly enabled for very good reasons and it´s harder to disable than on PC. Only a very small number of users actually unlock their phones, and an even smaller number play with fsync.It's my understanding that the whole data loss thing is an event that PCs are sensitive to, at least often enough to where it's been reported to the point where it's spread this far throughout the internet. I've had countless reboots unexpectedly from other issues, experiments, dead batteries etc...over the last 8 years without ever experiencing data corruption...in fact the only issues with unexpected corruption I've had have been due to Google's mutilated updates. Lol. Seriously though.
Yes, there´s the possibility of "dynamic" fsync. That means you might only lose data from when your screen was last enabled and fsync will happen when the screen is off in the best case.It's also my understanding that fsync doesn't have to always be off. If dynamic fsync is introduced, it automatically switches back on when the screen turns off. I'm not arguing or trying to persuade you to do anything that you don't feel comfortable with, but it is honestly the only reason I stopped using this kernel. If anything, I'm just giving my 2 cents in case it interests you enough to look into it a bit more. Thank you for all of your amazing work.
If you find anything interesting about the exynos roots let me know.One last thing...I installed a few Samsung specific, rather Exynos specific kernel managers after digging through the galaxy threads and they expose some more options on our devices such as MIPS Dynamic voltage min/max, and IRQ control. I'm still trying to learn more about Exynos crap because it's foreign to me, so I'm wondering if this could be advantageous.
There´s not much controversy about benchmarks for me. Benchmarks are simply tools for testing very specific scenarios.I knew benchmarks are a controversial topic but I've always liked to pull every bit of performance out of everything I've owned, whether it be a phone, car, my shlong ( couldn't resist) and I've already been able to shut those annoying **** talking Xiaomi Mi10 ultra guys up by dominating 100% of their devices on 3d mark while still not having to charge my phone for 24 hours or keep a fire nearby
Additionally to that filesystems are a lot further than 5-10 years ago, where this idea originates from.Dynamic fsync (the fsync replacement driver faux123 wrote a long time ago) is pretty much dead and causes nothing else than crashes and random reboots on modern / newer versions of the Android adapted Linux kernel.
Maybe what you mean is replacing the default fsync with asynchronous fsync instead?
By reading the instructions in the first post of this thread.
Did you update PixelFlasher lately? I updated PF to the latest thinking all my settings would still be set. But unless you reactivate Advanced option, your advanced settings will not be used and that includes disable verity and disable-verification options in PF.No, I did it from the start. I have been running this Kernel for a while, just having an issue recently
you need to give a lot more detail as to what you're talking about. overheating is likely related to your own personal use and background app activities. or give any details for troubleshooting
At least you read at one point through the requirements and instructions, although too lateBit of an odd one here, well it is for me...
I unlocked bl this morning, flashed EvoX rom, followed by magisk alpha, then kiri kernel. All went fine, and seems fine still. However, this is my 1st pixel and I just assumed that I could flash kiri in the normal way with fkm, apart from requiring a magisk module alongside it. But after reading through faq's for the kernel I see I should have disabled verity and verification at the time of flashing...
The odd part comes here; using the avbctl module it tells me both are disabled already (note: I haven't manually disabled anything myself or used pixel flasher/android tools etc for it to happen). See screenshot. So, my query is, do I still need to start a fresh, wipe everything and disable both at the start OR am I good to go and the terminal output is correct?
Also, if I am definitely disabled on both, any info on how this can be without my doing would be greatly appreciated!
I have only;
Unlocked bl
Flashed vendor_boot.img
Wiped
Sideloaded rom and magisk alpha
Booted
Got up n running with all apps etc etc then flashed powerhint and kiri.
No idea how verity and verification are automatically disabled
Like @ffuser1 said custom roms are not really supported and that's one of the reasons. I can't control what each custom ROM does and there's no way for me to track.It's possible the rom disabled them. Custom roms are not supported so you're probably on your own. You should be able to flash stock kernel if you run into trouble, unless your rom has its own custom kernel.