OK, didn't see the kernel was updated. Just flashed, will report back. Is it bad to share the dmesq log in and way?
Yes module is unchangedIs the powerhint module for 1.0.1 the same as 1.0.0? It's still labeled v7.
yesIs the powerhint module for 1.0.1 the same as 1.0.0? It's still labeled v7.
I need the contents of sys/fs/pstore after the device booted back up. dmesg shows only logging of the currently running session.OK, didn't see the kernel was updated. Just flashed, will report back. Is it bad to share the dmesq log in and way?
Using the newest magisk Delta 22510. And I'm on 1.0. no problems or reboots whatsoeverUpdate 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
Same here. Still sticking with 1.0.0. I want to enjoy the F2FS driver updatesAs much of an update junkie as I am, I may sit 1.0.1 out since I have no issues with 1.0.0.
I would remove cool tensor since it will most likely conflict with the powerhint module if it also alters processor frequencies. Leave the powerhint module there v7 and give the system a day or so to settle in. Battery life should be comparable to stock or a bit better. This and most modern phones get toasty with normal operation. With my case on and ambient temp around 22-23c my battery hits 33-36c doing stuff like web browsing, TG, videos etc.Anyone else's phone get super hot since flashing this? Anyone experiencing worse battery life? I have a feeling it's just me, but I don't really know what to try. What does the powerhint module do exactly? Should I try removing it?
This is my first custom kernel on this phone. I was on 1.3.0 from a few days ago until today when I flashed Raviantah 1.0.1, same overheating issue on both (though it's a bit better since installing the Cool Tensor mod a couple of hours ago). Honestly battery life is my #1 concern with this phone because it dies on me at least once every day, so maybe stock was the better fit for me...? Or should I be getting better battery life with this?
No, don´t remove the powerhint module. Kernel and module are meant to be run together.Anyone else's phone get super hot since flashing this? Anyone experiencing worse battery life? I have a feeling it's just me, but I don't really know what to try. What does the powerhint module do exactly? Should I try removing it?
This is my first custom kernel on this phone. I was on 1.3.0 from a few days ago until today when I flashed Raviantah 1.0.1, same overheating issue on both (though it's a bit better since installing the Cool Tensor mod a couple of hours ago). Honestly battery life is my #1 concern with this phone because it dies on me at least once every day, so maybe stock was the better fit for me...? Or should I be getting better battery life with this?
no, the kernel released here is only for pixel 7 and pixel 7 pro due to several reasons.Um anyway.... is this flashable for another device that have 5.10 kernel base? I heard that 5.10 is Generic Kernel Image
I removed Cool Tensor already. It was worth trying but didn't help, and it seemed to negatively impact performance. (May have been due to a conflict as you suggested.)I would remove cool tensor since it will most likely conflict with the powerhint module if it also alters processor frequencies. Leave the powerhint module there v7 and give the system a day or so to settle in. Battery life should be comparable to stock or a bit better. This and most modern phones get toasty with normal operation. With my case on and ambient temp around 22-23c my battery hits 33-36c doing stuff like web browsing, TG, videos etc.
Thanks for the info and suggestions. It's late here but I'll investigate further tomorrow and report back if I find anything useful.No, don´t remove the powerhint module. Kernel and module are meant to be run together.
There´s no reason the kernel would run hotter than the stock kernel or overheat if you´re not pushing the phone by gaming or other intensive tasks. In fact it runs cooler due to the PMU limiting.
That said the kernel won´t magically disable physics. If your ambient temp is 30°C the phone will run a lot warmer than on 20°C ambient temp.
Sounds to me like you´re either using a mods that´s conflicting or an app/service is stuck and is constantly requesting resources, which leads to your situation.
What might help you:
Check cpu usage with top command. Go to terminal or connect via adb shell, grant su rights, type "top" without the "". Rotate the phone to landscape and check if an app is constantly on top.
I´ll attach an example of how it looks on my end.
If an app like facebook, instagram etc is constantly on top eating more than 10% in the CPU section you might have found the issue.
View attachment 5870833
Check the logcat. If an app is spamming constantly multiple errors per second you might know what´s up.
Ultimately even simple things like adblocking can cause those issues. I once run into an issue, where an app tried to access a location that was being blocked by adaway. Instead of quitting after some time the app just tried over and over, which put a lot of load on the CPU and broke deepsleep.
nope as mentioned in the release postSo there are other changes with 1.0.1 too (reasons to upgrade) aside from fixing the null pointer?
Nope, Clear Calling is still there.Running March 2023 with Kirisakura_Raviantah v1.00 and Panther Module 7. I just noticed that the CLEAR CALLING option has disappeared from my Settings > Sounds & vibrations settings page. Can anyone else confirm? It was there when I was running on the stock kernel.
Running March 2023 with Kirisakura_Raviantah v1.00 and Panther Module 7. I just noticed that the CLEAR CALLING option has disappeared from my Settings > Sounds & vibrations settings page. Can anyone else confirm? It was there when I was running on the stock kernel.
Thanks for confirming @schmeggy929
"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.
It's not worth it to disable fsync or disable write barriers. The performance gain is nowhere near the benefit of having your data be intact.@Freak07 Any chance you'll implement a toggle to disable fsync?
@Freak07 Any chance you'll implement a toggle to disable fsync?
It's not worth it to disable fsync or disable write barriers. The performance gain is nowhere near the benefit of having your data be intact.
Android is not stable enough to run without fsync, as when Android begins crashing it'll come down hard and not in any graceful manner. When things start going awry there is no way to easily sync, there is no guarantee that the battery can sustain for long enough to sync writes to storage, or that the data can be written without potentially clobbering the file system.
The device is fast enough, the storage speed is fast enough, the penalty for safety is negligible.
All a toggle does is guarantee a user will enable it for "free performance." It's not free.
You pay the safety tax on your data, because if you don't then it only takes one (1) crash for it to be gone.
I formatted my Pixel XL with F2FS and set nobarrier, the performance benefit was only about ~20% on writes, and then it corrupted on the first crash.
It's never worth it.
I couldn´t have said it better myself than @Namelesswonder did.Good points. The only reason I mentioned it is because F2FS is pretty stable now. Honestly, the Android operating system as a whole has matured quite a bit and stability has greatly improved over time.
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