HipKat
Recognized Contributor
Wait, one Kernel for both 6's and 7's?
Wait, one Kernel for both 6's and 7's?
I'm on 25.2 and everything is working swimmingly.Are you missing some commas there? Do you mean "stable, canary, or canary 25206"? I'm on regular magisk 25.2. Can I flash this over pantah 1.3.0?
Didn't face a reboot on my end, and I'm running the release for longer already.Anyone getting random reboots since installing the merged kernel? Wasn't happening yesterday and I don't think I've made any other changes that could be the culprit. I've had it happen twice now while watching a video with the YT app. Dunno if that's related to the frames change?
Thanks, i can see the problem. it's a panic in f2fs driver.
I'm just glad it wasn't something I did as I was very confused. Thanks for taking a look and the quick response! Will look out for the update thanks!
It doesn't fix itself, the codepath that causes the panic is just not used and therefore the crash not triggered. Seems you were "lucky" and it happened a few times in short succession. If it's always during video playback or a certain scenario that might help to reproduce after testing a fix, but no problems with YouTube on my end.After rebooting maybe like 4 more times? Now it's been running 15 mins with no reboot and literally I have made no changes. Idk if thats normal where it can just fix itself? I'm not as knowledgeable on the specifics.
So far, not happening hereAnyone getting random reboots since installing the merged kernel? Wasn't happening yesterday and I don't think I've made any other changes that could be the culprit. I've had it happen twice now while watching a video with the YT app. Dunno if that's related to the frames change?
Correct, which will cause a full wipeAs I'm out of the root scene since quite a lot, I miss some new things.
Even if I'm rooted with Magisk, I need to disable vbmeta flags to flash a custom kernel, right?
Thanks for the report, seems like 1.1.5 misses the commit again...I may have misunderstood the post from August addressing the "W libperfmgr: Failed to write to node:/sys/module/teo/parameters/UTIL_THRESHOLD_SHIFT with value: 6"
It looked like you mentioned including a fix for this but it's filling up my logs. What do you think?
feel free to test and report back if that fixes the issue on your end as well.I may have misunderstood the post from August addressing the "W libperfmgr: Failed to write to node:/sys/module/teo/parameters/UTIL_THRESHOLD_SHIFT with value: 6"
It looked like you mentioned including a fix for this but it's filling up my logs. What do you think?
No worries, it´s good you reported it.Okay cool. It was one of those questions that has literally zero ill intentions behind it, yet no matter how carefully I tried to word I found that I sounded like a **** every time I read it back to myself. I was hoping it would end up being helpful and irrelevant so I could absolve myself of all dickheadism
That´s another good observation it seems. On my end it´s set to 0x0003, which is also the value it should end up with.Another question. I've found that some kernels that are said to have multi-gen LRU enabled, Don't have it enabled at all when I check under Sys/kernel/mm. I've been enabling it with a script as well as setting the minimum TTL the same way. Other kernels, mostly more recent ones I have noticed do have it enabled, and then there's sultan's which has it removed, I'm assuming it's related to emerald Hill. I do know that it has multiple features and it's suggested by Google to enable all of them which would give you a value of 0x0007. Then there's what I see most often which is 0x0003, and then lastly, I believe it was yours that is set at 0x0001. What are your thoughts regarding this and how you decided what to enable and what to leave disabled? I had been manually setting it to all on and min_ttl at 2000 but as I began to notice builds coming with it enabled already. I've always seen the value at 5000
0x0001: the multi-gen LRU core
0x0002: walking page table, when arch_has_hw_pte_young() returns true
0x0004: clearing the accessed bit in non-leaf PMD entries, when
CONFIG_ARCH_HAS_NONLEAF_PMD_YOUNG=y
on property:persist.device_config.mglru_native.lru_gen_config=none
write /sys/kernel/mm/lru_gen/enabled 0
on property:persist.device_config.mglru_native.lru_gen_config=core
write /sys/kernel/mm/lru_gen/enabled 1
on property:persist.device_config.mglru_native.lru_gen_config=core_and_mm_walk
write /sys/kernel/mm/lru_gen/enabled 3
Nothing past the last u beta 5.3 on their git as of now.Hi @Freak07, has Google posted the source code for the September kernel yet? I've been traveling in a completely different timezone so somewhat confused with Google's timing right now!![]()
Good question, I basically waited for it. The answer is: Yes most probably.This kernel https://forum.xda-developers.com/t/...l-for-pixel-7-pro-a-september-3-2023.4623789/ was posted recently and it claims that it doesn't need dm-verify disabled. I haven't tried it or looked at how this was accomplished or what compromises he had to make if any.
Is this something that might make it's way into this kernel some day?