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!

It is imperative that you read and understand the following:

As many of you know KernelSU has been rapidly evolving over the last month or so, and getting caught up has been quite the process. Neutrino is now current with KSU v2.1.2 (22164), which means I recommend using the equivalent official KSU Manager CI or newer:

https://github.com/tiann/KernelSU/actions/runs/19726628479

The latest CI of 5ec1cff's KSU Manager fork (formerly MKSU) is also supported:

https://github.com/5ec1cff/KernelSU/actions

These are the only two supported KSU Manager variants, there's really no good reason not to use the official CI's right now, but the choice is yours.

If you haven't been keeping up, I highly suggest that you educate yourself on the ways in which KernelSU has changed. The main point to be aware of is that KernelSU no longer handles module mounts natively, but rather uses a metamodule to handle mount operations:

https://github.com/tiann/KernelSU/blob/d00b4cc03717259815abf8b497ac73ca772e9bb8/website/docs/guide/metamodule.md

This change is only relevant to those of you using modules that mount /system. Otherwise, the way you interact with KSU Manager on a surface-level will not change.

SuSFS has been updated to v2.0.0, and has also seen significant functional changes in line with KernelSU updates. As you know I was already implementing a stripped down version of SuSFS in the past, and it is now more minimal than ever.

This was not my decision, although I'm thrilled to have SuSFS as small as possible, a good chunk of its previous functionality has been deprecated upstream and is no longer relevant to KSU in its current form.

What this means in practice is that there is no longer any automated functionality, TRY_UMOUNT operations are now handled exclusively by KSU, the only core feature that persists is SUS_MOUNT and even then it is only relevant when using a metamodule to perform /system mounts.

TL;DR - SuSFS no longer does anything unless you assign sus_mounts via userspace daemon.

I think for the time being I'll go back to shipping KSU-only releases unless there is a particular demand for Magisk-compatible variants, which it didn't seem like there was when I was running them.