ef842dda2a
This is mostly a libctru bug (well, sort of). This can only happen to built-in sysmodules, and to processes waiting for err:f, that fail to obtain handles through svcConnectToPort first try; and only prior to 11.0. Prior to fw 11.0, kernel didn't zero-initialize output handles, and thus the output handle gets filled with junk (leaked kernel stack data) in case of failure. Libctru does not account for this, and closes such handles anyway (in srvInit, errfInit, and possibly more). The problem is that, in our case, that garbage was equal to 0x8000, actually a valid handle, in fact the first handle to be created (and not closed) in a process... a handle to KAddressArbiter. Accidentally closing this handle resulted in one or more KIPs spin-waiting and starving core1, resulting in an inability to boot. We fix this simply by replicating what recent k11 does, in kext (for svcConnectToPort). For srvGetServiceHandle, add two layers of safety.
3ds_sm
Open source replacement of the Arm11 SM system module. This is licensed under the MIT license.
Usage
To run this system module, use a recent release or commit of Luma3DS, build this project and copy sm.cxi to /luma/sysmodules/.
Credits
Everyone that helped me fix some of stupid bugs I had been making: @fincs, @Hikari-chin, etc.