- Oct 28, 2026
- 4
- 0
- 1
- CPU:
- AMD Ryzen 3 3200U (Picasso), 2 cores / 4 threads
Hi everyone,
I need help diagnosing a freeze before the macOS Recovery GUI on an HP 255 G7.
Hardware and software:
The clearest comparison is between minimal configurations with NootedRed and both TSC-sync kexts disabled:
In T15 I kept cpus=2 and enabled NootedRed 0.8.10 with -NRedNoAccel. The new OpenCore log confirms the argument and NootedRed injection. The screen still stops around:
IOHDIXController: NOTE: administrator is creating non-ejectable disk image
ForgedInvariant and AmdTscSync 2.0.0 have already been tested separately without reaching Recovery. The AMD physical core-count patches remain 02. IONVMeFamily is excluded successfully in these diagnostic boots; the PM991 remains physically installed.
The attached ZIP contains:
No final custom UTBMap is present in the available files. The OpenCore logs stop at EXITBS:START; the later DLIL/IOHDIX messages are documented in the photos.
Could someone help interpret the CPU-count dependency and suggest a specific next diagnostic step? I would like to avoid repeating the same tests or changing several variables at once.
Thank you.
I need help diagnosing a freeze before the macOS Recovery GUI on an HP 255 G7.
Hardware and software:
- Ryzen 3 3200U (Picasso), 2 cores / 4 threads, Vega 3, 8 GB RAM.
- HP board 85EA, Insyde BIOS F.33; UEFI mode, Secure Boot and Legacy disabled.
- Samsung PM991 256 GB, firmware HPS4NFXV.
- Ventura 13.4.1 Recovery / Darwin 22.5.0; OpenCore 1.0.9 DEBUG.
The clearest comparison is between minimal configurations with NootedRed and both TSC-sync kexts disabled:
- T9, cpus=1: the photo shows 1 CPU and DLIL Proceeding, but Recovery never appears.
- T10, no CPU limit: the photo shows 4 CPUs and DLIL Waiting, without Proceeding.
- T14, cpus=2: the photo shows 2 CPUs and Proceeding, then freezes before Recovery.
In T15 I kept cpus=2 and enabled NootedRed 0.8.10 with -NRedNoAccel. The new OpenCore log confirms the argument and NootedRed injection. The screen still stops around:
IOHDIXController: NOTE: administrator is creating non-ejectable disk image
ForgedInvariant and AmdTscSync 2.0.0 have already been tested separately without reaching Recovery. The AMD physical core-count patches remain 02. IONVMeFamily is excluded successfully in these diagnostic boots; the PM991 remains physically installed.
The attached ZIP contains:
- An English test summary.
- Redacted configurations and OpenCore logs.
- The last complete received EFI, from T14, and the separate prepared T15 config.
- Original ACPI tables, the Windows USB scan and boot photos.
No final custom UTBMap is present in the available files. The OpenCore logs stop at EXITBS:START; the later DLIL/IOHDIX messages are documented in the photos.
Could someone help interpret the CPU-count dependency and suggest a specific next diagnostic step? I would like to avoid repeating the same tests or changing several variables at once.
Thank you.
