Ryzen 9800X3D + X870E + RX 6900 XT + RTX 5090 dual-GPU hackintosh — build log and current problem

[mrt360]

Goal​

I'm consolidating a separate Intel Hackintosh and Windows gaming PC into a single dual-boot workstation.

macOS -> RX 6900 XT only
Windows -> RTX 5090 + RX 6900 XT

The RTX 5090 does not need to function in macOS. Ideally macOS would not even enumerate it.

Hardware​

CPU: Ryzen 7 9800X3D
Motherboard: Gigabyte X870E AORUS Elite WiFi7
GPU (macOS): XFX RX 6900 XT
GPU (Windows): Zotac RTX 5090 (this plan is to deactivate in Mac OS)
NIC: Intel I226-V PCIe (AppleIGC)
PSU: be quiet! Dark Power Pro 13 1600W
Case: Lian Li O11 Dynamic EVO XL

Current layout:
• RTX 5090 horizontal in Slot 1
• RX 6900 XT upright using the EVO XL upright GPU kit (Slot 3 connection)

OpenCore​

OpenCore 1.0.7
SMBIOS: MacPro7,1

Kexts:
Lilu, VirtualSMC, WhateverGreen, AppleALC, AppleIGC, AMFIPass, RestrictEvents, AppleMCEReporterDisabler, NVMeFix, USBMap

Boot Args:
-v keepsyms=1 debug=0x100 agdpmod=pikera alcid=11 npci=0x2000 dart=0

What Works​

With only the RX 6900 XT installed:
• Sonoma boots reliably
• Photoshop 32-bit HDR confirmed working
• USB fully mapped
• Apple ID / iCloud working
• Intel I226-V is en0 with IOBuiltin=Yes
• Windows boots independently via BIOS F12 → Windows Boot Manager
• LSI 9211-8i HBA working correctly

The machine is completely stable in this configuration.

The Problem​

As soon as the RTX 5090 is installed and powered:

• BIOS output appears on the 5090
• OpenCore picker appears on the 5090
• Verbose boot appears on the 5090
• RX 6900 XT remains dark throughout the entire process

Boot then loops on:

AppleUserHIDDrivers
ITE Upgrade Mode(128)
VID:04D8 PID:57DB

Behaviour Matrix​

RX 6900 XT only → Boots normally

RTX 5090 installed and powered →
OpenCore displays on 5090
RX 6900 XT receives no signal
Infinite ITE / AppleUserHIDDrivers loop

RTX 5090 physically removed → Boots normally

RTX 5090 installed but power disconnected →
Gigabyte POST code 99
No POST

ACPI / PCI Mapping​

RTX 5090
01:00.0 → \SB.PCI0.GPP0.VGA
01:00.1 → \_SB.PCI0.GPP0.HDAU

RX 6900 XT
11:00.0 → \_SB.PCI0.GPP7.UP00.DP40.UP00.DP40.EP00

The two GPUs are on completely separate PCIe branches:
RTX 5090 → GPP0
RX 6900 XT → GPP7

Additional Investigation Already Performed​

OpenCore DeviceProperties

Attempted to disable the RTX 5090 using:
PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)
disable-gpu = 01000000

Result:
• OpenCore still displayed on the RTX 5090
• Verbose boot still displayed on the RTX 5090
• RX 6900 XT remained dark
• Same ITE / AppleUserHIDDrivers loop

PCIe Slot Changes

Tested the RX 6900 XT in multiple slots.

Result:
• No change
• RTX 5090 remained the primary display device
• Same boot loop

Linux PCI / ACPI Investigation

Mapped PCI devices to ACPI paths under Ubuntu.

Confirmed:
RTX 5090 -> GPP0
RX 6900 XT -> GPP7

Behaviour With RTX 5090 Removed

• OpenCore boots normally
• RX 6900 XT becomes active
• Sonoma reaches desktop
• System remains stable

Behaviour With RTX 5090 Present

• GOP output transfers to the RTX 5090 before OpenCore loads
• OpenCore picker appears on the RTX 5090
• Verbose boot appears on the RTX 5090
• RX 6900 XT never receives a signal
• System enters the repeating ITE Upgrade Mode loop

Current Theory​

The issue may not be the NVIDIA display device itself, but something associated with the entire GPP0 branch.

Because:
5090 absent -> macOS works
5090 present -> macOS fails

DeviceProperties-based GPU disabling made no difference.

Questions​

• Has anyone successfully hidden or suppressed an RTX 50-series GPU from macOS on AM5 while keeping an AMD GPU active?
• Has anyone seen the repeating ITE Upgrade Mode / AppleUserHIDDrivers loop in a dual-GPU configuration?
• Has anyone used an SSDT to suppress an entire PCIe bridge (e.g. GPP0) under Darwin rather than disabling only the GPU function?
• Does GPP0 suppression sound like a sensible next avenue to investigate?

​

 

[Edhawk]

Honestly, combining both the GPUs in one system is going to cause you unnecessary problems. The Nvidia GPU will not play nicely if it is set as the main display out connection.

The best you can do is set the Nvidia GPU in the second PCIe slot, vertically using the x16 slot adapter. Have the AMD GPU in the first x16 slot and use a custom SSDT to disable the Nvidia GPU when you boot in to macOS.

The AMD card will not work correctly if the Nvidia card is set as the primary display out in the bios.

Keeping the two systems separate is not a bad thing, given the incompatibility of the Nvidia card.

 

[etorix]

Does GPP0 suppression sound like a sensible next avenue to investigate?

Not quite: This is the direct PCIe root to the CPU and your AMD GPU hangs from the chipset, which is not a satisfactory setting for a main GPU.

Two separate builds looks like the most sensible option, even if it implies two sets of RAM.

If you absolutely want to have a single build, I'd suggest to change the motherboard for one which has TWO PCIe slots from the CPU, with x8/x8 bifurcation.

 

[mrt360]

Not quite: This is the direct PCIe root to the CPU and your AMD GPU hangs from the chipset, which is not a satisfactory setting for a main GPU.

Two separate builds looks like the most sensible option, even if it implies two sets of RAM.

If you absolutely want to have a single build, I'd suggest to change the motherboard for one which has TWO PCIe slots from the CPU, with x8/x8 bifurcation.

Honestly, combining both the GPUs in one system is going to cause you unnecessary problems. The Nvidia GPU will not play nicely if it is set as the main display out connection.

The best you can do is set the Nvidia GPU in the second PCIe slot, vertically using the x16 slot adapter. Have the AMD GPU in the first x16 slot and use a custom SSDT to disable the Nvidia GPU when you boot in to macOS.

The AMD card will not work correctly if the Nvidia card is set as the primary display out in the bios.

Keeping the two systems separate is not a bad thing, given the incompatibility of the Nvidia card.

Thanks for the replies. The point about the GPU hanging off the chipset rather than connecting directly to the CPU is noted — two separate builds may ultimately be the right solution, and I'm keeping that option open.


However, I'm currently trying to get the 6900 XT working in a single-GPU configuration with the RTX 5090 completely disconnected from the motherboard — no PCIe slot, no power cables. Even in this simplified setup I'm still experiencing the black screen at GPU driver handoff after verbose completes. Windows boots perfectly every time, which rules out a hardware fault.


The system was stable on this exact hardware before a BIOS reset event on 6th June, so I know the combination can work. I've since rebuilt the config as close as possible to the pre-break baseline including WhateverGreen, agdpmod=pikera, npci=0x2000, SSDT-USB-Reset, SSDT-NOBT and OpenVariableRuntimeDxe, but haven't been able to recover consistent stability.


Has anyone run a 6900 XT successfully on X870/X870E in a single GPU configuration? And would a 6800 XT be more likely to behave on this platform?

 

[Edhawk]

Is you AMD GPU an RX 6900 XT or an RX 6700 XT?

Your signature says you are using an RX 6700 XT, but you are asking for help with an RX 6900 XT.

The RX 6700 XT won’t work with WhateverGreen.kext, it requires NootRX.kext to work in macOS.

Some RX 6900 XT cards require a fake device-id to work in macOS, usually the XTXH variants, your PowerColor card may require the device-id fix in the DeviceProperties or via a custom SSDT.

 

[mrt360]

Is you AMD GPU an RX 6900 XT or an RX 6700 XT?

Your signature says you are using an RX 6700 XT, but you are asking for help with an RX 6900 XT.

The RX 6700 XT won’t work with WhateverGreen.kext, it requires NootRX.kext to work in macOS.

Some RX 6900 XT cards require a fake device-id to work in macOS, usually the XTXH variants, your PowerColor card may require the device-id fix in the DeviceProperties or via a custom SSDT.

Thanks Edhawk. To clarify — I have both cards available and I'm happy to use whichever gives the most stable build. My priority is stability.

The card is a PowerColor Red Devil RX 6900 XT. Device ID is 0x73BF so it should be the standard XTX variant. No device-id spoof has been added.
Current config for the 6900 XT:

WhateverGreen.kext + Lilu.kext
Boot args: -v keepsyms=1 debug=0x100 agdpmod=pikera alcid=11 dart=0 npci=0x2000 e1000=0
MacPro7,1 SMBIOS
SSDT-USB-Reset.aml, SSDT-NOBT.aml
OpenVariableRuntimeDxe.efi for emulated NVRAM
IOMMU disabled in BIOS
gpuswitch set to 0

Symptom: verbose boot completes normally, then black screen at GPU driver handoff. Machine is still running. Sometimes recovers after multiple retries or full PSU power cycle.

Windows boots perfectly every time.
The system was stable on this exact hardware before a BIOS reset event on 6th June. The config has been rebuilt as close as possible to the pre-break baseline but consistent stability hasn't been recovered.

Is there anything missing or incorrect in this config that could be causing the handoff failure? And if the 6700 XT would be more reliable on this platform, I'm happy to switch to that with NootRX instead.

 

[Edhawk]

I use a number of RX 6700 XT & RX 6750 XT cards (most are PowerColor) with no black screen issues. But I wouldn’t say they were any more reliable than the RX 6900 XT cards, when set correctly.

What happened with the Bios?

1. Did you end up re-flashing the same version of the bios on the system?
2. Did you flash a newer bios version on the system?
3. Or was it just a case of resetting the bios to system defaults?
4. Did you configure the bios to run macOS after the flash or reset?
5. If a newer bios version was flashed, have you generated new custom SSDT’s and checked the MmioWhitelist entries are still correct for your system?
6. Have you disabled the AMD iGPU in the bios?

I assume you have tried switching the display off and on again or to another display connector, to see if the screen initialises when it is reset to the normal display connector.

 

[mrt360]

I use a number of RX 6700 XT & RX 6750 XT cards (most are PowerColor) with no black screen issues. But I wouldn’t say they were any more reliable than the RX 6900 XT cards, when set correctly.

What happened with the Bios?

1. Did you end up re-flashing the same version of the bios on the system?
2. Did you flash a newer bios version on the system?
3. Or was it just a case of resetting the bios to system defaults?
4. Did you configure the bios to run macOS after the flash or reset?
5. If a newer bios version was flashed, have you generated new custom SSDT’s and checked the MmioWhitelist entries are still correct for your system?
6. Have you disabled the AMD iGPU in the bios?

I assume you have tried switching the display off and on again or to another display connector, to see if the screen initialises when it is reset to the normal display connector.

Thanks. To answer your questions:

The BIOS situation was a reset to defaults — not a flash or version change. After the reset I reconfigured the settings for macOS. I'm not certain whether all the original settings were restored correctly, which may be relevant.

To your specific questions:

No reflash — just a reset to defaults
No newer version flashed
Yes, reset to system defaults
Yes, reconfigured for macOS after the reset

No new SSDTs were generated after the reset — this could be significant. The MmioWhitelist entries have not been checked since the reset
The AMD iGPU has been disabled in BIOS

Regarding switching display connectors — yes, the black screen has occurred across different connectors and cables, and with single monitor configurations on both HDMI and DisplayPort.

The point about SSDTs and MmioWhitelist after the BIOS reset is something we hadn't fully addressed. Could this be the cause? If the BIOS reset changed memory mapped IO regions, would the existing MmioWhitelist entries no longer be valid?

 

[Edhawk]

No, not if all you did was use the system defaults in the bios. They would only come in to play if the bios were changed to a different version.

 

[Edhawk]

Have tried connecting to the Hack, from a real Mac or another Hack, using screen sharing? Does it show a black screen or the normal login screen?

 

[mrt360]

Have tried connecting to the Hack, from a real Mac or another Hack, using screen sharing? Does it show a black screen or the normal login screen?

Thanks Edhawk. I don't have a real Mac but I do have two other hackintoshes — a Ryzen 5 2600X build that's been running the 6700 XT without any issues, and an X299 build that the 6900 XT has been running stably on for years. I'll try screen sharing from one of those. Thanks.

Here's a full summary of everything tried so far:

GPU testing:
RX 6900 XT (PowerColor Red Devil, device ID 0x73BF, standard XTX) — black screen at driver handoff after verbose completes. This card has been running perfectly on my X299 hackintosh for years with just WhateverGreen + agdpmod=pikera, no special configuration needed.

RX 6700 XT — same black screen at driver handoff, plus USB initialisation loop (ITE Upgrade Mode / AppleUserHIDDrivers repeating in verbose). This card runs fine on my 2600X build with NootRX.

Both cards exhibit the same failure on the X870E, ruling out a card-specific issue

Kext/driver combinations tried:
WhateverGreen + agdpmod=pikera (standard Navi setup)
NootRX instead of WhateverGreen (one clean cold boot with Apple logo, then failed on subsequent boots)
agdpmod=ignore tested as alternative to pikera

Boot arguments tested:
agdpmod=pikera — standard, always present with WhateverGreen
npci=0x2000 — was in the pre-break working config but causes IOPCIConfigurator hang with Above 4G Decoding enabled
e1000=0 — tested and removed
dart=0 — present throughout
BIOS settings confirmed:
Above 4G Decoding: Enabled
Resizable BAR: tested both On and Off
IOMMU: Disabled
iGPU: Disabled
CSM: Disabled
Onboard LAN: Disabled
PCIe slot 1: Gen3
Config/ACPI items restored from pre-break EFI:
SSDT-USB-Reset.aml
SSDT-NOBT.aml (Bluetooth suppression)
BlueToolFixup.kext
AppleIGC.kext
OpenVariableRuntimeDxe.efi (was missing — NVRAM writes were blocked without it)

Other tests:
Single monitor only (both HDMI and DisplayPort, both monitors individually)
Different physical ports on the GPU
gpuswitch set to 0 in pmset
ReconnectGraphicsOnConnect = True (made things worse)
ResizeAppleGpuBars set to 0
Multiple cold boots (PSU power cycle) and warm restarts
NVRAM reset from picker

Key observations:
Windows boots perfectly every time on both GPUs
The 6900 XT has been running flawlessly on my X299 build for years
The 6700 XT runs fine on my 2600X build
The system was completely stable on the X870E before a BIOS reset to defaults on 6th June

The BIOS was reconfigured for macOS and new SSDTs generated before rebuilding

Verbose always completes normally — the failure is specifically at the GPU driver handoff to WindowServer
Sometimes recovers after unplugging a monitor's mains power mid-boot, suggesting a display handshake stalemate

Even the USB installer EFI (different config entirely) struggles to boot, suggesting a BIOS-level issue rather than config

I'll try the screen sharing test tonight and report back.

 

[mrt360]

Update: black screen / GPU handoff issue now appears to be resolved.

I’ve now had five successful boots in a row, including two full cold starts and a restart from macOS.

Current working boot args:

-v keepsyms=1 debug=0x100 agdpmod=pikera alcid=11 npci=0x2000 dart=0 e1000=0<br>

The main differences compared with the problematic config were:

• npci=0x2000 restored
• e1000=0 restored
• agdpmod=pikera retained
• dart=0 retained
• DisableVariableWrite kept enabled/true
• OpenVariableRuntimeDxe.efi retained
• OpenRuntime.efi retained

FIngers crossed this is problem solved!

 

[Edhawk]

As you don't have an Intel i225 or i226 Ethernet controller you don't need e1000=0 boot argument.

Also, once you are sure you have a working OC setup, you can remove/delete -v keepsyms=1 and debug=0x100.

I tend to use npci=0x3000 when the bios lacks the option to enable 'Above 4G Decoding'. But I never use both at the same time.

Your motherboard has a Realtek 2.5G Ethernet controller, so you shouldn't need any boot arguments for that device. Just the correct kext.

 

[etorix]

I have no hands-on experience with AMD systems (just hanging around here to learn…), but using BOTH "Above 4G Decoding" and npci=0x2000 is a typical setting with Xeon W-2000 and Xeon Scalable systems—against what Dortania advises for Core systems. I have eventually found out that doing IRQ patching with SSDTTime allows to remove npci=0x2000 for Xeon systems.

dart=0 should be redundant with disabling IOMMU in BIOS (AppleVTD does not work with AMD anyway).

That would leave agdpmod=pikera and alcid as last boot arguments.

 

[mrt360]

I have no hands-on experience with AMD systems (just hanging around here to learn…), but using BOTH "Above 4G Decoding" and npci=0x2000 is a typical setting with Xeon W-2000 and Xeon Scalable systems—against what Dortania advises for Core systems. I have eventually found out that doing IRQ patching with SSDTTime allows to remove npci=0x2000 for Xeon systems.

dart=0 should be redundant with disabling IOMMU in BIOS (AppleVTD does not work with AMD anyway).

That would leave agdpmod=pikera and alcid as last boot arguments.

Thanks both — that makes sense, and I appreciate the clarification.

I’m going to leave the EFI alone for tonight, as this is the first stable baseline I’ve had after several days of troubleshooting, so I want to be cautious about the next steps.

I agree that <span>e1000=0</span> is probably unnecessary in my case, especially as I’m not using Intel Ethernet. I’m currently using the Dell dock Ethernet rather than the onboard controller, so I’ll remove that later as a simple single-variable cleanup test.

I also take the point about <span>dart=0</span> likely being redundant if IOMMU is disabled in BIOS.

The one I’ll be most cautious with is <span>npci=0x2000</span>. The system is currently booting reliably with Above 4G enabled and <span>npci=0x2000</span> present, so I don't want to change that immediately. I’m not assuming it is required either — just treating it as part of the current working baseline until I can test properly. I just want to make changes 1 by 1.

One thing I’m trying to keep clear in my own head is that if I eventually clean up the boot args to just <span>agdpmod=pikera alcid=11</span>, that still won’t necessarily make this the same as the problematic EFI I was using before. The bad/recovery EFI differed in other areas too, not just boot args — NVRAM handling, OpenCore driver/kext state, ACPI set, and possibly quirks such as <span>DisableIoMapper</span>. So I don’t want to assume the boot args were the whole story.

Longer term, I agree the cleaner target is probably just:

<span>agdpmod=pikera alcid=11</span>
with the verbose/debug args removed once I’m done troubleshooting. But I’ll get there gradually: remove one argument, test restart and cold boot, then move to the next.