sceKernelHasTrinityMode returns 0, the answer of a base PS5, as
sceKernelIsTrinityMode already does. Two public readings of firmware
libkernel (OpenAGC for 11.60, Backport for 11.00 to 12.70) say it
compares hw.sce_main_socid with its low five bits cleared against
0x840fc0; the base PS5 SoC id recorded for sceKernelGetMainSocId,
0x840f80, fails that test. The prototype int (void) comes from the 23
calls in a UE5 title, each storing setne of the result in a guarded
static with no argument set up.
Titles import it from libkernel, but only the libkernel_sys placeholder
inventory exported it, as a throwing stub. The export moves to libkernel
next to sceKernelIsTrinityMode, and the inventory and its counts drop
the entry. guest_operation_mode checks the result.
The mutex yield step counts each yield in a counter that
MutexYieldsForTest_nid_no_patch reads. With no spins and a yield count
of 5, a waiter woken while another thread holds its mutex must yield
exactly 5 times before it blocks, for each mutex type and for the outer
level of a recursive mutex held twice. With WakingLock::lock calling
the native lock directly the count stays 0 and the test aborts.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
FreeBSD 11.4's _mutex_cv_lock takes the mutex back through
mutex_lock_common, so a woken waiter tries once, spins and yields by
the mutex's counts before it blocks. The wait here called the native
lock directly; it now goes through the same spin and yield path as
scePthreadMutexLock.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
guest_timed_wait_cpu aborts on the Windows CI runner after printing the
scePthreadCondTimedwait(500 us) CPU line (job 124274871982, main
37277ea18f). The test requires the 99th percentile of each set of waits
under 3 ms and the longest under 10 ms. ctest runs it with --parallel 4
beside tests such as guest_usb_storage, guest_nanosleep_long_request and
the guest_raise tests. Their threads keep the runner's CPUs busy, so a
woken waiter can wait more than a scheduler quantum before it runs: a
failing run measured a 13.25 ms condition wait and a 23.3 ms usleep.
The test now runs with RUN_SERIAL on Windows, as guest_pthread_start and
audio_out2_timing do. The bounds are unchanged.
sched_getparam, sched_getscheduler and sched_setparam with the own pid
from a thread other than the main thread act on the main thread once it
has registered through scePthreadSelf, as FreeBSD's p1003_1b.c selects
the first thread. Before registration, after the main thread exits and
on macOS they still throw.
MihawkOS (PPSA99170) reads sysctl {1, 14, 8, 0} while it starts and the
runtime throws on the unsupported MIB, which aborts the title.
KERN_PROC_PROC takes no pid, so the node lists the one guest process the
runtime hosts, as the same kinfo_proc kern.proc.pid already builds.
AI-assisted: yes
FreeBSD's mutex_lock_common tries the lock before mutex_lock_sleep
spins or yields, so a free mutex with yield loops and no spins was
yielding before its first try here.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Dean