[GUIDE] DSDT override eGPU error 12 fix
[GUIDE] DSDT override eGPU error 12 fix (Windows only)
A Windows system's DSDT table root bridge definition (ACPI PNP0A08 or PNP0A03) is usually confined to a reserved 32-bit space (under 4GB) budgetted to be large enough to host the notebook's PCIe devices. A watermark TOLUD value is then set and locked in the system firmware. Windows OS honors the root bridge definition and will allocate PCIe devices within it. macOS ignores the root bridge constraints as too does Linux when booted with the 'pci=noCRS' parameter. Neither of those OS require a DSDT override and can allocate freely in the huge 64-bit PCIe address space.
When retrofitting a eGPU, an error 12 (This device cannot find enough free resources that it can use) can occur against an eGPU in Windows' device manager making it inoperable. This can indicate there is insufficient 32-bit addressing space available to host the eGPU. An eGPU requires a relatively large PCIe config space to allocate into. Decreasing TOLUD by reducing RAM to 2GB offers a somewhat impractical workaround. Rather, the definitive solution is below.
This three step solution removes Window's 32-bit PCIe allocation constraint in order to resolve the eGPU error 12:
macOS users: refer instead to Mikeal's post that covers these steps titled Windows 10 - Clover DSDT memory override [UEFI Windows on Macbooks only].
|Step 1. Create a dsdt-modified.aml DSDT file with a 36-bit root bridge
OPTION 1: Use the Intel method
OPTION 2: Use the Microsoft method
|Step 2. Load your dsdt-modified.aml as a registry override or in-memory substitution
OPTION 1: Load your dsdt-modified.aml as a registry override with Windows test signing mode enabled
OPTION 2: Avoid test signing mode - load your dsdt-modified.aml as an in memory DSDT substitution
|Step 3. Confirm success with a 'large memory' area in Device Manager
1. I still have an error 12 with the 'large memory' area present. How can I fix it?
2. How do I disable the registry DSDT override?
Windows 10 or 8 enumerates the DSDT table from the in-memory copy on every boot. The only way to change that is to either:
- perform a registry DSDT override with test signing enabled as described in the above post. Do not that some apps are either problematic or refuse to run with test signing enabled.
- perform an in-memory DSDT table substitution using nando's DIY eGPU Setup 1.35 pre-boot environment which eliminates the need to alter your registry or enable test signing as explained in this post.
|How to do a in-memory DSDT override using nando's DIY eGPU Setup 1.35?|
How to load your dsdt-modified.aml via DIY eGPU Setup 1.35
1. Copy your dsdt-modified.aml file as dsdt.aml into Setup 1.35's v:\config directory
2. Boot into nando's DIY eGPU Setup 1.35 -> automated startup via startup.bat (default).
It will automatically load this dsdt.aml file and present the Windows bootloader where you then select Windows. Check for the 'Large Memory' area to indicate a successful in-memory DSDT override like shown below in View->Devices By Connection. Then check for error 12 against your eGPU..
3. If there is an error 12. then force allocate the eGPU into the DSDT override's 36-bit PCI space:
- At Windows boot menu, select Setup 1.35
- Boot Setup 1.35 -> menu-based
- Select PCI compaction->Endpoint=56.25GB (36-bit)
- Select PCI compaction->Run compact. When prompted for the scope select eGPU, force 32-bit=none.
- Select startup.bat->Test Run.
- Select Chainloader->Test Run
- At Windows boot menu, select Windows.
|Does this work?|
Yes. Below we see the new 'Large Memory Area' indicating the PCI BUS now extends into 36-bit PCI space with the iGPU (didn't have an eGPU at hand) relocated into that 36-bit space.
Hello there! no problem.
@nando4 I still have the same problem.. the eGpu insists to connect to other Pci root port, instead the one created under the large memory... What should I do?
I already unistall all the ports, the eGPU and the nvidia drivers, but it still not connect to the large memory..
Posted by: Yukikaze
Samuel, I think that Setup 1.35 should be able to fix that, because I believe you can force it to allocate the eGPU to the large/high memory area. I am not sure if there is a way to do it without Setup 1.35, but nando might know how to.
If the eGPU won't auto-allocate to the 'Large Memory' area, then revert to using eGPU Setup 1.35 software to hard allocate it in a pre-boot environment.
@everyone, the opening post is presented with an up-to-date DSDT override example using a 4th gen i-core Dell E6540. Unfortunately previous discussion was deleted along with the thread due to an offsite issue. Sincerest apologies there.
Thanks @nando4, that did the trick It wouldn't run without setup 1.35 and compacting. After 2 days of tinkering with DSDT. I needed to cut "If (COND) FPED" statement and paste to where OS's are listed. Also added QWORD. Now that I know what I'm doing it's 2 min.
In my experience with my X230 and an Expresscard eGPU, the latest Lenovo X230 BIOS has no TOLUD problems. My HD7950 worked with it without any DSDT overrides or any Setup1.3x remapping of the eGPU. As far as I know, though, the X220 never got such a BIOS update.
"Always listen to experts. They'll tell you what can't be done, and why. Then do it."- Robert A. Heinlein, "Time Enough for Love."
here ◄ is Mikeal's updated second revision of this article
Update Feb-2019 >>Mac users are advised to use @goalque's automate-eGPU EFI instead of Clover to load your resultant DSDT override to avoid issue noted below in the BIG WARNING.
BIG WARNING by nando4 >> @Goalque has correctly identified that Clover loads a DSDT table in firmware volume and as such can brick a Macbook as this user found. If you proceed with using Clover to do a DSDT override the you do so at your own risk!! For risk-adverse users it is suggested to simply do a DSDT registry override and persevere with Windows' test signing mode until other solutions are found and presented.
Update: I still have an error 12 with the 'large memory' area present. How can I fix it?
Update: my internal soundcard doesn't work after applying this fix. What can I do?
Just wanted to let you know how it went for me. I also have the late 2016 MacBook Pro 460. I tried Mikeal's method and it worked perfectly.
However, one issue/side effect. If I boot up with both the Razer Core and the USB-C to USB adapter, it would give me the Code 12 Error. Only when I disconnected it and boot up with the RC, does it work. (to be clear, adapter with an usb device attached such as mouse or keyboard)
After booting up, you can connect the adapter normally.
It's kinda weird or maybe something wrong with my system allocation but the adapter somehow screws up the reallocation.
Hope this helps.
Are you using the USB adapter on the same side the core is connected? I stopped using that one because I was having issues and thought it was because they shared the thunderbolt controller. I switched to a cheap ankar USB-C to 4 port USB 3.1 adapter on the other side. Even if the core side 2nd adapter was working for me, it got bad performance(Oculus complained about tracking). I have no problem running all 3 sensors and the Rift off the other side though.
Hi，Devaspark @ Devaspark
I have the Macbook pro 450 and I also use Mikeal's way to deal with the problem of the Code 12 Error. However, I have the issue of the DSDT compilation. Do you have this error: code 4096, unexpected PARSEOP_IF, expecting“,"or")"
If you have fixed the same errors, would you like to tell me how to do? Thank you.