9800X3D / ASUS TUF B850M-PLUS WIFI / RX 6900 XT - Tahoe recovery freezes before installer

plawpp

New member
AMD OS X Member
Oct 30, 2026
3
0
1
CPU:
9800x3d
Hi everyone,
I'm trying to install Tahoe on this PC, but I haven't managed to reach the recovery screen. OpenCore loads the recovery image and verbose boot starts, then it stops around CoreAnalyticsHub / early IOKit initialization. I left earlier attempts for five minutes with no change. A fresh test still stops at the same stage.
Specs:
  • CPU: Ryzen 7 9800X3D, 8 cores / 16 threads
  • Board: ASUS TUF GAMING B850M-PLUS WIFI, BIOS 1065 (original WIFI model, not WIFI7)
  • GPU: RX 6900 XT, device ID 1002:73BF; monitor connected by DisplayPort
  • RAM: 48 GB DDR5, EXPO 6000
  • SSDs: Samsung 990 EVO Plus 1 TB (macOS target), Lexar ARES PRO 1 TB, aigo P7000Z 2 TB
  • Tahoe 26.6.2 recovery, build 25G83 / Darwin 25.6.0, on a Kingston USB
  • OpenCore 1.0.8 DEBUG, MacPro7,1
Last checked BIOS settings: CSM off, Secure Boot off, Above 4G on, ReBAR on. ResizeAppleGpuBars is 0.
What I've tried so far:
  • AMD core-count patches set to 8, updated Tahoe PCI/TSC patches, and the AM5 PCI-enumeration patch enabled.
  • DevirtualiseMmio and SetupVirtualMap enabled, with F7000000 and E0000000 in the MMIO whitelist.
  • Updated Lilu to 1.7.3 and VirtualSMC to 1.3.9. Tried cpus=1 earlier without improvement; it is now removed.
  • Tried NootRX earlier. The current test has it disabled and uses the AGDP board-id patch without WhateverGreen.
  • Most recently, blocked IONVMeFamily and disabled NVMeFix for a USB-recovery-only test. The recording shows OpenCore reporting exclusion Success, but it still stops before recovery. All three SSDs remained physically connected.
Current boot-args:
-v keepsyms=1 debug=0x108 -lilubetaall io=0x80003f iokit_print_verbose_match_logs=1
The latest screen repeats "IOResources: family specific matching fails" and ends with a configuration-thread termination message. I don't know which thread is actually blocked.
Two things I should mention: USB is still using USBToolBox + UTBDefault; I haven't made a proper port map yet. The EFI also contains a locally modified DebugEnhancer and an early-console kernel patch added during troubleshooting. I haven't ruled out those changes affecting the result.
I've attached the EFI used for this test and a screenshot of the last screen. SMBIOS details are removed, and DebugEnhancer's debug symbols were stripped to remove local build paths. The original DSDT is at the top level of the ZIP for reference.
Could someone check whether there's an obvious problem in the ACPI/PCI setup? What would be the best way to get a useful trace at this point, or establish a cleaner baseline?
Thanks for taking a look.
 

Attachments

  • boot-stuck.jpg
    boot-stuck.jpg
    852.1 KB · Views: 4
  • EFI.zip
    EFI.zip
    7.7 MB · Views: 4
Boot using OC Debug version, so a boot log is generated. This will highlight any initial boot issues, such as ACPI errors plus it will show the MmioWhitelist entries you need to use to boot macOS.

 
Thanks Edhawk. I have captured three physical-machine boot logs using OpenCore 1.0.8 DEBUG with Target=67, AppleDebug and ApplePanic enabled. The attached ZIP contains sanitized logs and a short README.

Since my original post, I have replaced UTBDefault with a USBToolBox map created by testing the ports in Windows. I also completed the Tahoe installation onto the Samsung 990 EVO Plus through VMware using the physical SSD, but it still does not boot to the desktop on the real PC.

AppleMCEReporterDisabler is now enabled for MacPro7,1, and all three logs show successful prelinked injection. NVMeFix is enabled again, and the previous IONVMeFamily block has been removed.

The logs cover two installed-system boots and one KINGSTON USB recovery boot. All three stalled, and I manually restarted the PC.

All three show successful DSDT patch replacements, applicable AMD/PCI patches, and eight kext injections. They end at EXITBS:START and do not capture the later on-screen kernel output. No saved panic file was found.

The MMIO results are identical:

0xE0000000 0x10000 pages skip 1
0xF7000000 0x7E00 pages skip 1
0xFEE00000 0x1 page skip 0
0xFEE01000 0x11FF pages skip 0
0xC80000000 0x20200 pages skip 0
My local PE_init_kprintf diagnostic patch is Not Found in both installed-system boots, but matches once in recovery. The modified DebugEnhancer is still enabled, so this is not yet a clean baseline.

Could you review the logs and suggest the useful changes to test next?

Thank you for your help.
Boot using OC Debug version, so a boot log is generated. This will highlight any initial boot issues, such as ACPI errors plus it will show the MmioWhitelist entries you need to use to boot macOS.

 

Attachments

Success with Sequoia on this motherboard was reported here:
I'm surprised that you went so far without SSDT-CPUR or equivalent.
So you may
  • Add SSDT-CPUR.
  • Try Sequoia first.
  • Enable all the ACPI patches (or try different combinations to find out which ones are necessary).
  • Remove the NVMe. I'm not sure if any of the three is macOS-friendly.
 
Thanks, Edhawk, for recommending DEBUG logs, and thanks, etorix, for pointing me to the B850 success story.

I’ve now got Tahoe installed and booting on bare metal using the 1401 workflow. After the initial setup, Wi-Fi and Bluetooth weren’t working. I looked up similar cases and fixed Wi-Fi support for the RZ616. I then redid the USB mapping so the Bluetooth device was mapped correctly; Bluetooth started working after a full power-off. Ethernet is also working, and the RX 6900 XT is using macOS’s native AMDRadeonX6000 driver.

The USB mapping is still incomplete: some ports run at USB 2.0 speeds, so SuperSpeed isn’t available on every port yet. That’s enough for my current use.

After comparing the EFI and the boot logs, I still can’t tell exactly where the original boot problem was. The EFI configuration changed between the original attachment and the later tests, and all three logs stop at EXITBS:START without capturing the kernel output after that point. So I don’t have enough information to identify a specific setting or patch as the cause.
 
I assume you added SSDT-CPUR.aml table to your EFI, following @etorix advice, that probably would have been the ‘fix’ that got you past the OC startup phase. As all B550, B650 & B850 Hacks require that SSDT or a custom SSDT-PLUG-ALT.aml (from SSDTTime).
 
  • Like
Reactions: etorix
✖
  AdBlock Detected
Sure, ad-blocking software does a great job at blocking ads, but it also blocks some useful and important features of our website. For the best possible site experience please take a moment to disable your AdBlocker.