Just a heads up for anyone who might be interested, you can expect a new release tomorrow as long as nothing goes sideways.

Apologies for the extended downtime, I did switch devices recently, but probably not the device you might be expecting.

For this reason, I'll be continuing to support Pixel 9 for the foreseeable future (because I absolutely cannot afford a 10 Fold) 👍

I've had a couple people reach out to me regarding what appear to be soft reboots on recent builds. This is problematic as these are not caused by a kernel panic directly, and thus no ramoops is generated.

Obviously, this is not something that I am experiencing personally. I wouldn't release builds that were unstable (for me), and I don't have any indication that this is a common occurrence for the majority of users.

If you are one of those people, however, and you want me to attempt to address your concern then I need you to take an active role in troubleshooting, as I unfortunately cannot debug an issue that I don't have. At a minimum, knowing how to reliably induce the bug would be helpful.

In the case of indirect soft reboots where a kernel panic doesn't occur, I would need a dmesg dumped either to the device or your PC that captures the event, ideally beginning prior to the crash until the reboot occurs. Alternatively, dumping dmesg as soon as humanly possible after a soft reboot is less ideal, but may still be helpful.

I would also ask you to consider running through a process of elimination on any mods you may have installed in order to ensure that they aren't contributing to the issue. If you are able to identify a problematic module, let me know, and I can take it from there.

As far as logcats are concerned, I will take them with an accompanying dmesg, but a standalone logcat isn't particularly useful to me as it provides very little in the way of tangible information about the kernel, but can be useful as an adjunct.

The nature of the beta/stable relationship is such that sometimes cross-compatibility is possible, and sometimes it isn't.

I understand that there may be Bluetooth and/or WiFi issues on QPR1 with the latest release.

Unfortunately that means your options are to not use the kernel, or move to QPR2 depending on what is more important to you.

Neutrino has always been based on the current beta kernel sources, and it always will be. I don't use or test on stable, and I won't entertain issues that are exclusive to stable.

6.1.155-NeutrinoKernel

https://github.com/0ctobot/neutrino_kernel_google_caimito/releases/tag/6.1.155-NeutrinoKernel

I've re-uploaded the latest release with some hotfixes to improve the performance and stability of SuSFS v1.5.11 as well as to address a niche side channel detection vector for KSU.

Please note the 20251006 build date to confirm you're flashing the most recent zip.

Obviously, I have not yet obtained QPR2 beta 3 kernel sources as it was just released today, nevertheless this build is compatible with today's beta update (BP41.250916.009.A1)

ATTENTION:
As you will no doubt notice, there are two zips attached to this release - it's very important that you comprehend the following in order to ensure that you flash the correct one. I've taken a bit of an experimental turn here and have compiled the standard kernel, as it always has been, with KernelSU and SuSFS, and well as a variant without KernelSU for those who might be interested in using this kernel with Magisk.

- If you are a regular user and wish to continue using this kernel with KernelSU, please flash the first zip labeled with KSU
- If you are a Magisk user who would like to try the kernel, please flash the second build that does NOT have the KSU label

Please do not interpret this as a guarantee or commitment that I will always release variant builds for both root solutions, I may or may not choose to continue doing this going forward. Thanks!