Nov 22, 2016 - Check your DSDT under _PWR to see which address is used, it's either 0x0D or 0x6D and patch it accordingly. This should work with both.
No more 4GB+ system RAM issues: use a DSDT override to extend the root bridge into 36-bit space (Windows 7/8/10 only - MacOS/Linux are unaffected) Introduction This problem and solution is only relevant to Windows operating systems. MacOS ignores the root bridge and can allocate in 64-bit space as kizwan found. Linux has a 'noCRS' kernel parameter to ignore the root bridge boundaries so the OS can also also allocate in full 64-bit pci-e space.
The this process aims to solve the problem of seeing an error 12 (This device cannot find enough free resources that it can use) issues against a eGPU in Windows Device Manager due to insufficient 32-bit addressing space. By manually adding a memory range outside of this 32-bit space, we can force Windows to operate in 36-bit space instead to host eGPUs. Know systems that will require this process are Dell Latitude Ex410 series, Samsung Series-4, Sony F-Series and MSI CRx20, HP-Elitebook/Probook xx60x/xx70x with AMD GPUs. Those have insufficient free 32-bit PCI space to accomodate a eGPU if have 4GB or more of RAM installed. They can't use PCI compaction to create sufficient space because they either have TOLUD=3.5GB, have lower TOLUD like 3.25GB but with an unmovable systemboard device occupying candidate free pci space making it unusable or are using an AMD or GTX650/GTX750 card that requires over 256MB contiguous space. Refer to ( 2.
How can I check if my notebook is compatible with an eGPU?) for details on how to check your TOLUD. The same solution can be applied to any 3-gens old PM965 chipsets (2007) or newer system.
They have a 64-bit CPU and chipset so are fully PAE-36-bit/64-bit compatible. Dell Inspiron 1440/1525 (core2duo) and Dell Vostro 1015 (core2duo) have BIOS-configured 36-bit root bridges already so don't require this workaround. I happened to run into one of these problematic systems. A Dell E4310 with TOLUD=3.5G which can be maxxed out at 16GB of RAM. It's too nice an ultraportable to be need to downgrade RAM to 3GB of RAM to use an eGPU.
I set of in pursuit of how to add a DIY eGPU to it which is documented below. Using 36-bit PCI compaction on the eGPU to relocate it in such space will see the eGPU still give an error 12 in Device Manager.
Avlan that the 32-bit root bridge definition limited allocation only to 32-bit space. The fix being a modified DSDT loaded as a registry override that extends the root bridge (ACPI PNP0A08 or PNP0A03 device) into 36-bit space. Avlan's fix was cryptic so wasn't attempted on other systems. After a bit of digging from the following references I found the QWORDMemory DSDT static resource entry can be used to easily extend root bridge entry into 36-bit space. Ref: plus two examples at.
Tools required The iasl and asl tools used are in or (older). Allternatively, can download them from their original sources:. The latest Windows Binary Tools (WBT):.
The Windows Driver Kit (WDK), which contains the Windows ASL Compiler:. Notepad (or any other text editor) Step-by-step DSDT override Need a 36-bit root bridge DSDT override The test Dell E4310's root bridge was extended into 36-bit space with the steps below. See also, user angerthosenear's alternative instructions to those presented below where can use a DSDT Editor to simply the patching process if experience a compilation error. Capture the DSDT table using command below.
This gives a raw dump of the ACPI tables in.dat files. Dsdt.dat is the one we will be using. Newer versions of iasl no longer having the '-g' option in which case use acpidump instead. Iasl -g acpidump -b 3.Decompile dsdt.dat to get an output dsdt.dsl text file that can be editted: iasl dsdt. Open the resultant dsdt.dsl file and look for the PNP0A08/PNP0A03 'DWordMemory' resource entries.
Under the last DWordMemory entry in that area, add a 'QWordMemory' (64-bit) entry shown as the second paragraph below. I ensure that I stay in the 36-bit range (Resources by Connection-Memory as shown below. The same fix was done on a Dell E4300 and Win7 did automatically allocate the eGPU into the 36-bit space. If you still see error 12 then there are two options to pursue:.
Re plug'n'play the devices. Go into Device Manager - Video cards, delete the eGPU. Also go into Device Manager - System devices and delete the PCI Express Root Port x entries. Upon restarting the system, halt Win7 startup with F8, attach and power on your eGPU and then proceed to load Win7. Win7 should now be clever enough to re-allocate the eGPU into 36-bit space upon realizing there is insufficient 32-bit space to host it. Can go one step further and delete your eGPU NVidia/ATiAMD driver, restart the system and reload it.
That may help as well. Hard allocate the eGPU into 36-bit PCI space before booting Win7 using. Select PCI compaction-Endpoint=56.25GB (36-bit) and then select Run compact.
When prompted for the scope select eGPU. The result will be similar to that shown in the spoiler in step 8 above, but with the eGPU rather then the Intel HD iGPU being in 36-bit PCI space.
Can then proceed to automate this by editting your%DRV%: config startup.bat (or V: config startup.bat in windows) so can just select the Automated startup via startup.bat Setup 1.30 bootitem and have it do everything for you: call speedup lbacache call vidwait 300 call vidinit -d%eGPU% call pci call chainload mbr Testing results.: SUCCESS! Allocated the eGPU into 36-bit space. Allocated the eGPU into 36-bit space. Allocated the eGPU into 36-bit space. Dell E4310 (Tech Inferno Fan): SUCCESS!
I relocated the Intel HD iGPU into 36-bit space using Setup 1.30 as shown in step 8 above freeing 256MB of contiguous 32-bit space to host an eGPU, so it will definitely work. Plus there is plenty of 36-bit space for the eGPU too. Unfortunately my PE4L 2.1 isn't working so I can't show the iGPU+eGPU both being active but it will work.: SUCCESS! His HD5870 successfully relocated to 36-bit pci-e space. When do I need to hotplug my eGPU to overcome the error12 with a DSDT override?. How to clean the DSDT override properly?
(kizwan) (.We will need to delete DSDT key in registry) HKEYLOCALMACHINE SYSTEM ControlSetXXX services ACPI Parameters DSDT. where XXX are 001, 002, 003 & so on.
And HKEYLOCALMACHINE SYSTEM CurrentControlSet services ACPI Parameters DSDT I didn't really tested whether deleting 'DSDT' key in ControlSet XXX ( XXX are 001, 002, 003 & so on) really necessary but I will test this when I test your latest Setup 1.30. For sure deleting 'DSDT' key in CurrentControlSet is necessary. So, you can put it in.bat file.
Win8/10: Perform a DSDT substitution within to overcome TOLUD issues Win8 enumerates the DSDT table from the in-memory copy on every boot as it's default behaviour. The only way to get it to allow a Win7 style is to enable test signing for the Windows bootloader (bcdedit) as described. An alternative method was also discovered to overcome this Win8 limitation without resorting to a DSDT override. The way it works is by substituting the in-memory DSDT table with one that extends the PCI bus into 36-bit PCI space done within the pre-boot environment.
Steps to do this are below:. Identify your DSDT table's starting address using r-w everything. The shows it is 0xC6FF3198 for my E6230.
Obtain the system DSDT table ('iasl -g'), then add the QWordMemory entry to extend the root bridge out to 36-bit space as described in the to file.dsl. Compile the new DSDT table 'iasl file.dsl' and compare the resultant dsdt.aml size to your file.dat obtained using 'iasl -g'. Now here's the tricky bit. The dsdt.aml file must be.smaller. than the original in-memory DSDT (file.dat) otherwise it overwrites some additional ACPI tables beyond the DSDT and will cause Win8 boot to crash.
To get my compiled dsdt.dml to a size smaller than file.dat, I removed the unnecessary Win95/XP/WinME entries in the OSI method from my file.dsl then compiled it with 'iasl file.dsl'. Copy your resultant dsdt.aml to your Setup 1.30 disk image or USB key config directory.
Load your modified DSDT table into memory with 'pt MEM writefromfile 1 address of DSDT table dsdt.aml'. In my case this command was 'pt MEM writefromfile 1 0xC6FF3198 dsdt.aml'.
Perform PCI 36-bit PCI compaction on the eGPU by setting the endpoint to match the override, ie: 56.25GB. This may not be strictly necessary as Win8 cleverly relocates devices in available PCI space when 32-bit PCI space is tight. In this example, my Dell E6230 had TOLUD=3.25 meaning plenty of 32-bit PCI space for an iGPU+eGPU. I forced allocated the iGPU into 36-bit space using Setup 1.30's compaction just as a proof-of-concept. Chainload to Win8. It will enumerate the DSDT based off the in-memory substituted version. Automating it.
Once confirmed it all works, use (Setup 1.30 menus) or edit v: config startup.bat (Windows) and add your 'pt MEM writefromfile' line from (5) so you can boot and just select Setup 1.30: automated startup via startup.bat or just let it countdown to select that by default. Does this work?
Indeed it does!! Below we see the new 'Large Memory Area' indicating the PCI BUS now extends into 36-bit PCI space with the iGPU relocated into that 36-bit space.
The same process also useful to certain systems whose fan profiles can be altered in the DSDT table. Avoid Win8's Secure Boot Anybody upgrading to Win8 is advised to disable their bios UEFI/secure boot so it uses MBR boot instead. Then Setup 1.30 can chainload to Win8 without any problems. Otherwise users requiring Setup 1.30 functionality would need to do a Win8 re-install to change the partitions from UEFI to MBR.
Not sure if I am being completely blind, but I am running a Dell Precision M6500 that has 8GB of RAM. I have managed to get the DSL file (that part was easy), but trying to edit it, isnt proving to be easy. I cannot seem to find any DWordMemory entries under PCI0 which is PNP0A03. My device manager breakdown looks like. ATTACH=CONFIG12275/ATTACH The DSL file can be found here.
Looks like the M6500 uses DSDT code that matches exactly what that noted in. The same code snippet can be found above the first 'Return (CRS0)' line you find in yor dsdt.dl file. Suggest incorporating the 36-bit root bridge addition code Avlan highlights. I really suck at explaining but I think the best way to go at it is this one. Use the iasl.exe to dump the table and decompile it.
Add the QWordMemory part and compile it. If loading the table with asl /loadtable doesn't work then do the following. Take the.aml file that came out of iasl.exe and take it to the folder with asl.exe (The version that I linked worked for me, the one in WDK 8.1 did not.) Decompile that file with asl /u filename Rename that file into something else and open it with your editor of choice. Now dump your DSDT table with asl /tab=DSDT This makes another asl file, open it up with your editor. Get to Device(PCI0) in both and compare the two buffers. The one that you disassembled from iasl.exe should have differences like the one I posted (First line and last few lines) Since you added the 32 bit allocation with QWordMemory. Pretty much copy the buffer from the iasl.exe decompiled ASL to the asl.exe dumped ASL.
Save, run asl filename (The one you just saved of course.) This compiles, it gave me a few errors for a method which I commented/deleted out. Loaded it with /loadtable and now I have my large memory thingie. I haven't gotten my PCI adaptor yet but I will test it soon. It is of course not recommended to just delete something out of your table to make it compile so you might find another workaround for that. I really suck at explaining but I think the best way to go at it is this one. Use the iasl.exe to dump the table and decompile it.
Add the QWordMemory part and compile it. If loading the table with asl /loadtable doesn't work then do the following. Take the.aml file that came out of iasl.exe and take it to the folder with asl.exe (The version that I linked worked for me, the one in WDK 8.1 did not.) Decompile that file with asl /u filename Rename that file into something else and open it with your editor of choice. Now dump your DSDT table with asl /tab=DSDT This makes another asl file, open it up with your editor. Get to Device(PCI0) in both and compare the two buffers. The one that you disassembled from iasl.exe should have differences like the one I posted (First line and last few lines) Since you added the 32 bit allocation with QWordMemory. Pretty much copy the buffer from the iasl.exe decompiled ASL to the asl.exe dumped ASL.
Save, run asl filename (The one you just saved of course.) This compiles, it gave me a few errors for a method which I commented/deleted out. Loaded it with /loadtable and now I have my large memory thingie. I haven't gotten my PCI adaptor yet but I will test it soon. It is of course not recommended to just delete something out of your table to make it compile so you might find another workaround for that. After.myriad. attempts, each one of which came within a hair's breadth of bricking my laptop, this method worked for me.
I'm exhausted from the effort and will try to recreate my precise steps and post them here only in a few days, but the following might be useful signposts for others who, like me, never realized how much free time they have on their hands. (If I spent as much time and devoted as much grey matter to my job, I'd be CEO by now): 1. The basic idea is this: use nando64's excellent instructions to stick a QWordMemory allocation into your DSDT, but don't panic when you get all these useless, arcane, and incomprehensible errors at compile-time. Instead of trying to actually turn this into a good.dsl file, just comment everything away AS LONG AS YOU PRESERVE perfectly the initialization of the CRS table. Slash and burn as much as you like, as long as when iasl the file, you get no errors and you do produce an.aml file, and then when you apply asl /u to that.aml file, you get something with a CRS table that sorta looks a lot like artearte's.
Doing this preserves both your sanity - because you don't have to do things like worry about how to replace 'Buffer' with 'Package' when the word 'Buffer' doesn't actually appear in the.asl code - and also your laptop's sanity, because you never are going to load this emasculated.aml or.asl into its registry. All you want is that longer table, written out in ascii hex. (My values were slightly different than artearte's, although the length 0x1ee was the same.
Doh, 0x1ee is 36-bits of length that we all are trying to achieve). Once you have the table, THEN, you start again, and this time be as focused and careful as Elmer Fudd hunting Wabbits: You extract your DSDT with asl /tab=DSDT; then carefully change the definition of the CRS table to be the longer table from the file you made in the previous part, and now you might have an.asl file which will compile ('asl filename.asl'), then load ('asl /loadtable filename.aml') without incident.
One has to assume that it's the author(s) of iasl who need to be taken out and executed. It seems that iasl can't create a file which doesn't produce mind-bendingly annoying errors when compiled. But one can rely on it to produce correct snippets of.asl file, as long as one plays along with its little game of pretending to be a decompiler, and verifies the correctness of its output by commenting out most of it and compiling the rest.
The other perhaps useful thing to know is how to recover if you DO load a table which is bad. In my case, every attempt I made at truly fixing the output of iasl produced in the end and.aml file which loaded fine. But unfortrunately when I rebooted, the machine would BlueScreen a second or two after the Windows Logo appeared - which according to posts here is exactly when DSDT is loaded. No ordinary fix method of any kind ever got me past this; I was, however, able to boot and get a command prompt using installation media.
And from there I was able to bring up regedit and clear out the bad DSDT entries in the non-active C:-drive registry. (it seems to be a little-known if life-saving fact that you can edit the registry of an installation which is not the one you are actually running: see ). I now have a great big large memory, into which my GTX 760 can easily fit. I'm not sure if my memory is big enough for me to remember why it is I began this project, however. What.WAS.
I thinking? Oh yes, I remember. Well, perhaps the eGPU will work now. Thank you so much to all who helped.
I really suck at explaining but I think the best way to go at it is this one. Use the iasl.exe to dump the table and decompile it. Add the QWordMemory part and compile it. If loading the table with asl /loadtable doesn't work then do the following. Take the.aml file that came out of iasl.exe and take it to the folder with asl.exe (The version that I linked worked for me, the one in WDK 8.1 did not.) Decompile that file with asl /u filename Rename that file into something else and open it with your editor of choice. Now dump your DSDT table with asl /tab=DSDT This makes another asl file, open it up with your editor.
Get to Device(PCI0) in both and compare the two buffers. The one that you disassembled from iasl.exe should have differences like the one I posted (First line and last few lines) Since you added the 32 bit allocation with QWordMemory. Pretty much copy the buffer from the iasl.exe decompiled ASL to the asl.exe dumped ASL. Save, run asl filename (The one you just saved of course.) This compiles, it gave me a few errors for a method which I commented/deleted out. Loaded it with /loadtable and now I have my large memory thingie. I haven't gotten my PCI adaptor yet but I will test it soon. It is of course not recommended to just delete something out of your table to make it compile so you might find another workaround for that.
Hi artearte, Please could you upload your modified.dsl file for T430? I'm struggling with DSDT Override on my notebook, without success so far. I've changed from Windows 7 64 on MBR to Windows 8.1 64 on GPT and I'm trying to make it work with PE4C and GTX660. I want to post my experiences, since I think my experiences will help with troubleshooting.
I have been around computers my whole life, and I am a middle-aged man - have mostly worked with computers for utility, but have had programmer friends and consider myself a novice programmer. There are steps in this process that aren't entirely clear, so I will show how I got the egpu setup to work: (1)I ran up against a detection issue (Error 43) when installing the egpu. I have a Lenovo Thinkpad T400 (running Windows 8.1). I have a beast pcie board, 650w earthwatts antec psu, zotac gtx 660 graphics card, and viewsonic vt1900led. I used an HDMI connection to connect video card to monitor.
I tried to simply install recent drivers, but this did not fix the issue. I realized that I could not do anything more with just the hardware set up, so I contacted nando (and got the setup 1.3 software). Note:- This may seem like a silly thing, but it is something worth mentioning. Originally, I questioned whether my PSU was actually working. I also did not have the exact same size power connector cables in my PSU to match the cables provided by PCIE board to connect it to PSU.
(The connector cable of 24 pin cable was slightly larger - and also there were no six pin connectors coming from PSU - only 8 pin). Long story short, PSU only activates when entire setup is connected to computer. Otherwise, you won't see it activated.
Also, the fact that the power connectors coming from PSU had slightly more pins didn't matter - they could still be connected to the cables provided with PCIE board to connect to PCIE board. (2) I didn't do anything fancy to set up the software. I simply followed nando's instructions, so there aren't really any issues I can talk about that I ran into related to this part.
(3) I initialized the setup 1.3 software after restarting computer. I chose 'menu-based' option and hit F5 (eGPU setup had to be on).
The software recognized it. The new software allows you to hit F1 to get explanations of menu items which is helpful. I think I chose PCI ports - Enable all ports - and the Zotac showed up in the box to the side with the port where it is attached to. (4) I realized at this point that I would have to do a DSDT override (to ensure that I would have enough available memory freed to run card). There were a couple of interesting parts to this journey: -Instead of using the WBT Tools link (where software didn't fully work for me), I had to navigate to DIY eGPU experiences 2.0 thread page 27, where user spanning provides a link to a DSDT editor LinuxWindows that actually did work for me.The WDK kit software did not work for me. I had to navigate to link in this thread artearte provides for the 4.0 ASL compiler.
This did work for me. (5) I should mention that at this point, I think I was having some trouble with the DSDT process, or I just decided to run a compaction in setup 1.3 - chose the large option (I think it is 48GB or something) and chose to compact IGPU & EGPU - and restrict EGPU to 32 bit. This did not solve my problem of error 43, but I thought it is worth noting that I tried this step. (6) I had originally followed all the DSDT override code steps up to inserting the code QWord Memory items into the dst file. When I opened dsl file (used notepad for this), I originally could not find the DWord Memory entries.
I had searched and found nothing. I actually had to physically scroll down to find them (a simple step I know - but something worth noting). Upon pasting the code, this step worked out.
(7) Another thing worth noting has to do with the aml file. For those who are new to programming, you actually have to drag that file into the compiler folder before initiating it with command prompt code. Again - this seems like a simple thing, but not everybody who is doing this have been programming for years. (8) The other code steps went through fairly straightforward, and now it was time to return to setup 1.3 (at this point I'm still getting code 43). I run compaction again (this time same 48GB option - or the larger memory option - and chose eGPU for compaction only and chose no restriction for 32 bit space). I restarted crossing my fingers - and again - code 43.
(9) Here's where things get interesting. I read in some forum about eGPU (can't remember what post) where simply inserting expresscard after boot does something. There was nothing.
Not even a detection in Device Manager. I was like - OK - I guess that didn't work. Then I restart, and boom - no Error 43 and graphics card driver detected and working fine. Simply inserting expresscard after boot. No code - no fancy stuff. (10) So I'm like- Ok - great - but monitor still is not being detected. I tried installing driver (btw this monitor has Windows XP driver - you have to actually click on option to let driver install when you doubleclick it - it will say something like driver is not compatible - but I think I just decided to hit OK eventually and it installed).
I was like - Ok - I guess I'll go back to caveman thought - and unplug hdmi from card, and plug it back in, and then unplug hdmi from monitor, and plug it back in - and Boom - monitor detected in control panel display options. So I'm telling this story not because I'm a fancy programmer - but because I'm a simple man, and I had to actually figure out some simple steps that may help an average joe actually get their eGPU setup working.
After.myriad. attempts, each one of which came within a hair's breadth of bricking my laptop, this method worked for me. I'm exhausted from the effort and will try to recreate my precise steps and post them here only in a few days, but the following might be useful signposts for others who, like me, never realized how much free time they have on their hands. (If I spent as much time and devoted as much grey matter to my job, I'd be CEO by now): 1. The basic idea is this: use nando64's excellent instructions to stick a QWordMemory allocation into your DSDT, but don't panic when you get all these useless, arcane, and incomprehensible errors at compile-time. Instead of trying to actually turn this into a good.dsl file, just comment everything away AS LONG AS YOU PRESERVE perfectly the initialization of the CRS table.
Slash and burn as much as you like, as long as when iasl the file, you get no errors and you do produce an.aml file, and then when you apply asl /u to that.aml file, you get something with a CRS table that sorta looks a lot like artearte's. Doing this preserves both your sanity - because you don't have to do things like worry about how to replace 'Buffer' with 'Package' when the word 'Buffer' doesn't actually appear in the.asl code - and also your laptop's sanity, because you never are going to load this emasculated.aml or.asl into its registry. All you want is that longer table, written out in ascii hex.
(My values were slightly different than artearte's, although the length 0x1ee was the same. Doh, 0x1ee is 36-bits of length that we all are trying to achieve). Once you have the table, THEN, you start again, and this time be as focused and careful as Elmer Fudd hunting Wabbits: You extract your DSDT with asl /tab=DSDT; then carefully change the definition of the CRS table to be the longer table from the file you made in the previous part, and now you might have an.asl file which will compile ('asl filename.asl'), then load ('asl /loadtable filename.aml') without incident. One has to assume that it's the author(s) of iasl who need to be taken out and executed. It seems that iasl can't create a file which doesn't produce mind-bendingly annoying errors when compiled. But one can rely on it to produce correct snippets of.asl file, as long as one plays along with its little game of pretending to be a decompiler, and verifies the correctness of its output by commenting out most of it and compiling the rest.
The other perhaps useful thing to know is how to recover if you DO load a table which is bad. In my case, every attempt I made at truly fixing the output of iasl produced in the end and.aml file which loaded fine.
But unfortrunately when I rebooted, the machine would BlueScreen a second or two after the Windows Logo appeared - which according to posts here is exactly when DSDT is loaded. No ordinary fix method of any kind ever got me past this; I was, however, able to boot and get a command prompt using installation media. And from there I was able to bring up regedit and clear out the bad DSDT entries in the non-active C:-drive registry. (it seems to be a little-known if life-saving fact that you can edit the registry of an installation which is not the one you are actually running: see ). I now have a great big large memory, into which my GTX 760 can easily fit.
I'm not sure if my memory is big enough for me to remember why it is I began this project, however. What.WAS. I thinking? Oh yes, I remember. Well, perhaps the eGPU will work now.
Thank you so much to all who helped. Could somebody explain the last part of this post? How exactly can you clear our the bad DSDT entries in the non-active C: drive? Hello everyone currently i work on my dsdt override, and need some help: Which one of those PCI Bridges is the right one for the dsdt override? I did get my dsdt.dsl file which can be opened with a text editor like Notepad:-P now i have to insert the new 'programm code', a new paragraph for the pci adress expansion:-) upon using ' iasl -oa XXXX.dsl' command to compile i got some errors:-( There are only two errors this time?? Ok well i had 140+ last time:-( Do i have to change something with this error according to the fixing guide? I can't just add some other commands arround it, that makes no sense to me.
I will append the file here as zip for everyone to download and have a look at it, maybe someone knows how to resolve them! Thank you for any advice for a possible fixing help. Hi I have a problem concerning my setup with thinkpad x230, 16gb ram, i7 and GTX 970. After an odyssey with without getting setup1.30 to work(thanks again for the patience and all the help ), I finally got it working with a DSDT Override manually. It worked fine with windows 8.1 for quite a long time and I could even plug and play the express card while running windows. Then I updated to windows 10 and even then it kept working awesome.
But today after like 2 weeks of gaming pause I tried plugging it in again and it did not work. So I looked if the GTX 970 is still in the device manager. Code 12 again. So tried hot plugging while booting in bios and all that stuff I had to try month ago. Without success.
Then I saw that there is no 'large memory' (which shows after DSDT override) anymore, so I thought the testmode is off, but it was not (or at least it showed on the bottom right corner still testmode on. But to be sure i activated again and tried, no success. Then even though i really didnt know anymore how to do the DSDT Override anymore I found the old links I'd done it the first time with. I even tried several approaches but all just give back 'ACPI Error' Bluescreen after reboot so I had to recover windows. Am I doing something wrong? Is the new windows 10 preventing the DSDT Override?
Do I need other tools than the ones for win8.1 for compiling and all the loading tables stuff? I think the Lenovo BIOS updated at some point recently, could it be that? I would really appreciate. Hi I have a problem concerning my setup with thinkpad x230, 16gb ram, i7 and GTX 970. After an odyssey with without getting setup1.30 to work(thanks again for the patience and all the help ), I finally got it working with a DSDT Override manually.
It worked fine with windows 8.1 for quite a long time and I could even plug and play the express card while running windows. Then I updated to windows 10 and even then it kept working awesome. But today after like 2 weeks of gaming pause I tried plugging it in again and it did not work. So I looked if the GTX 970 is still in the device manager. Code 12 again. So tried hot plugging while booting in bios and all that stuff I had to try month ago. Without success.
Then I saw that there is no 'large memory' (which shows after DSDT override) anymore, so I thought the testmode is off, but it was not (or at least it showed on the bottom right corner still testmode on. But to be sure i activated again and tried, no success. Then even though i really didnt know anymore how to do the DSDT Override anymore I found the old links I'd done it the first time with. I even tried several approaches but all just give back 'ACPI Error' Bluescreen after reboot so I had to recover windows. Am I doing something wrong? Is the new windows 10 preventing the DSDT Override?
Do I need other tools than the ones for win8.1 for compiling and all the loading tables stuff? I think the Lenovo BIOS updated at some point recently, could it be that? I would really appreciate. If the registry DSDT override doesn't seem to work in Win10 then apply a in-memory substitution in Setup 1.30 which will remain in place once you Chainload to Win10. Details of how to do that are at. If the registry DSDT override doesn't seem to work in Win10 then apply a in-memory substitution in Setup 1.30 which will remain in place once you Chainload to Win10. Details of how to do that are at That I do not get.
I mean the substitution is in place otherwise why would I get a bluescreen, or what do you mean? And how exactly do I chainload into win10? I mean what options in setup 1.30? Just doing the 'testrun' in chainload after i did the 'pt MEM.'
Command in the setup 1.30 command line? I also have the problem that the R-W Everything today just opens, fills my 16gb of ram completely and then gives an error after clicking the 'ACPI Table' button. What can i do about it? Yesterday when I first installed it, it worked fine.
That I do not get. I mean the substitution is in place otherwise why would I get a bluescreen, or what do you mean? And how exactly do I chainload into win10? I mean what options in setup 1.30? Just doing the 'testrun' in chainload after i did the 'pt MEM.'
Command in the setup 1.30 command line? I also have the problem that the R-W Everything today just opens, fills my 16gb of ram completely and then gives an error after clicking the 'ACPI Table' button. What can i do about it? Yesterday when I first installed it, it worked fine. I pointed out that if the registry DSDT override doesn't work then use the in-memory method instead.
Just note the precautions there. You must make the replacement DSDT table smaller than the original and you must load it into the correct memory address.
I cannot advise you about R-W everything use. Perhaps seek contact with the author if can't make any headway. I pointed out that if the registry DSDT override doesn't work then use the in-memory method instead. Just note the precautions there. You must make the replacement DSDT table smaller than the original and you must load it into the correct memory address.
I cannot advise you about R-W everything use. Perhaps seek contact with the author if can't make any headway. I got R-W Everything work so now I can confirm that the DSDT table was pulled while first putting it into the in-memory and then chainload with 'testrun' into win10 using the setup 1.30. But then again the ACPI Error bluescreen is showing. So is there something wrong with my dsdt.aml table file I am building? I tried creating the new dsdt table using your approach as well as the one here which is a lot faster and easier (but also correct?
Especially the 'fix error' part I am a bit unsecure about). And the only error I am getting (in both approaches) is. Name (IRC, 0x00) 'Reserved name must be a control method (with zero arguments)'.and some warnings and remarks but those I can ignore right? The thing is when I click 'fix errors' in the DSDT Editor it does something but the line does not change. Is the tool creating something elsewhere to fix it?
Edit: ok with a diff tool I saw that it 'fixes' it with changing the line ' Name (IRC, 0x00)' to ' Name (IRC, 0x00)' But that is not an actual fix right? Without the tool I used the fix I found on 'Brightbulb' which is not online anymore, but was especially for egpu with x230 16gb ram and worked before yesterday. I wanna make sure that everything is going to work fine with my laptop so i got some questions First of all my laptop is Lenovo Z51-70 CPU: I5-5200U 2.2ghz iGPU Intel HD 5500 dGPU:AMD R9 M375 Ram: 8GB (will raise it to 16GB) HDD: 1TB stock one SSD: 120GB (for my games and windows only) now i investigated a little about eGPUs and found that i need a M.2 or thunderbolt, i've found that my wifi card use a M.2 a/e key aka ngff, so i will be using the GDC Beast NGFF version to the bad part / question part What do i need to know other than the stuff above? What is the white-listing thing? I found on support forums that my laptop support some wifi cards only and it's bios cann't be modified according to bios modifying forums (not here) in same time saw some posts on reddit that says if ur bios have UMA graphic option then you will need to disable PAX / WIRELESS and enable UMA and it will work fine, the question is that true?
I wasn't able to find anyone who did it on Z51-70 i found only 1 post on reddit for Z41-70 (which after research found that both are using same M.2 a/e key slot and also same bios. But the one who posted only replied that it's recognized with some errors and never replied back with any updates so still not sure about it. Hello guys, Thanks for this incredible forum, I hope I will learn a lot from the gurus! I am trying to make my eGpu MSI GT X970 work on my laptop with K1100M integrated GPU.
This are my specs: CPU: 2.7GHz Intel Core i7-4800MQ (quad-core, 6MB cache, up to 3.7GHz with Turbo Boost) PSU:??? Graphics: NVIDIA Quadro K1100M / Intel HD Graphics 4600 RAM: 32 GB Storage: 1TB I got a V8.0 EXP GDC Laptop External Independent Video Card Dock with the express card version ( I am not really hw savy) and I am looking for a good psu to power my MSI GTX 970 4G Could you kindly suggest a good PSU that i could use to power this GPU? I am also willing to do as many experiments needed Thanks for reading my post -zepvalue. Hello everyone. I put on a eGpu setup after quite a bit struggle 2 years ago and I used play games just fine. After a while I sold my graphics card gtx 970.
Now since 2 days I am trying to put the eGpu setup back again this time with a Gtx 770. I couldn't understand the problem. I can shut my dGpu off with diy 1.30 setup. ( usb booted) And my laptop sees gtx 770 along with my igpu Intel HD graphics 4000. After driver installation when I try to play a game laptop is tring to use iGpu instead of Egpu. (tried to delete and install driver few times) With MSI afterburner I can see eGpu is%0 all the time.
Can it be power problem cause graphic cards fans ( Msi gtx 770 twinfrost ) are working all the time they dont stop. Or what else can it be. GUIDE DSDT override to fix error 12.
Well, I've got it built but not working yet. I decided to try the iBoot / Multibeast method but have run into a snag.
I've followed these directions to the letter. But on step 9, after the reboot I get the dreaded 'Verifying DMI pool data.' And it will not progress from there. Any ideas on the problem? I have the DVD in SATA 0, 1 TB HD in SATA 1, and a 1 TB HD in SATA 2. Thanks for any suggestions on this.
If I boot with the IBoot CD first and then choose the HD it will boot up. Jeff - To unsubscribe: HQ-A homepage: Options: Group files page: login: password: filespw PH 3/4/2011, 19:06 น. But on step 9, after the reboot I get the dreaded 'Verifying DMI pool data.' And it will not progress from there. You MUST specify AHCI mode and a 64-bit HPET. Do that immediately after specifying 'failsafe options'. I DO TRUST that this is NOT yet another failure of a G41M hack, like I had with my MSI G41M.
The older Gigabyte mobos with Award BIOSes have an ACHI module which they licensed from Intel, or some other licensor, who doesn't give a sh!t about hacks. I have more troubles with $50 G31 and G41 mobos than I EVER have had trouble with $80 P45, P55 and related mobos. P55M and P43M mobos are now cheap enough that there is seldom a reason NOT to go with them. Jeff 3/4/2011, 19:09 น. Thanks Peter.
I had 64-bit HPET already set. For the life of me I see no where in the BIOS to specify AHCI mode. Am I just blind? This will probably be my last Hack with the G41-ES2L. I had the MB for several months and finally decided to put it to good use. The 31- and 41-series, with their ICH7 Southbridges, may not have AHCI implemented, in which case there is no BIOS option necessary.
Mac Auto Fixer For Mac
64-bit HPET is certainly a requirement. I would load the 'failsafe' options, then go back and turn off all legacy ports (serial, parallel, floppy, PATA), then turn on the stuff which MacOS X expects, such as HPET. Boot drive options should be USB-FDD first (in case you have to FLASH the BIOS), SATA optical second and SATA hard third. Some mobos are finicky about having their legacy ports turned off.
In this case, you will have to experiment. PH 3/4/2011, 20:53 น. I'm using the latest version of the BIOS (F9) for this board according to the gigabyte site. How likely is it that the onboard audio is just not working? I tried to get something to play out of the speakers when using the Ubuntu Live DVD (with only booting with the DVD), not with installing Ubuntu 10.04.
Not too likely that the onboard audio is not working. I don't know why Gigabyte includes TWO audio devices. Only one is the correct one. Whichever one IS correct, you change that to HDEF. The other one, you delete altogether. My next thing to try is to make sure that I hooked it up correctly when I built it. I know there is a AC97 cord and a HD audio cord.
I'm pretty sure I used the later. It gets me that the 'About this Macintosh' shows the ports but it's not available in the Sound preferences in 10.6.7. Would anyone be so kind as to look over the two DSDTs? One is the original extracted DSDT using Ubuntu Live DVD.
It's of little use because it won't compile as is. The other is the one I modified for the use for the G41M-E2SL and is the one I'm using, with no sound. I used Peter's excellent tutorial on the google docs site (which borrowed from Tony Macs.) The DSDT info which I sent earlier covers all bases, I think. I have not known Gigabyte to ever use an address=2 codec, rather they have always (in my memory) used and address=0 codec.
Jeff 6/4/2011, 19:50 น. Well, I finally got the sound working.
I had to put HDAEnabler.kext in /E/E and now it works. I was under the assumption that all I needed was the Legacy8xxx.kext in /E/E and the dsdt would take care of the rest (of course had to do the AppleHDA.kext roll back to 10.6.2). That wasn't the case for me. I now have the two kext requrired for audio in /E/E and fakesm.kext in there as well from the iBoot / Multibeast install. Jeff - To unsubscribe: HQ-A homepage: Options: Group files page: login: password: filespw PH 7/4/2011, 8:22 น. I finally got the sound working.
I had to put HDAEnabler.kext in /E/E and now it works. I was under the assumption that all I needed was the Legacy8xxx.kext in /E/E and the dsdt would take care of the rest (of course had to do the AppleHDA.kext roll back to 10.6.2). That wasn't the case for me. I now have the two kext requrired for audio in /E/E and fakesm.kext in there as well from the iBoot / Multibeast install. For a properly designed and implemented DSDT sound device, all you need is: ALC8xxxHDA in /E/E, but AppleHDA rolled-back to 10.6.2. There are check-boxes for both of those in MultiBeast. Other audio hacks have to be removed from /S/L/E, of course.
Meaning no Azalia, no Voodoo, etcetera. AppleHDA has to be rolled back because Apple crippled many of the ALC8xx codecs, except for ALC885, which is native on Intel Macs. ALC8xxxHDA is the new, revised version of Legacy8xx, and is available in the later versions of MultiBeast.
It's pretty important to keep up-to-date on MultiBeast as there are occasionally unadvertised fixes contained in the updates. The latest update includes formal support for the final version of the universal R8xxx gigabit Ethernet kext, but, alas, it still does not work for R8169. PH 7/4/2011, 11:47 น. This new tool, from the same team which produced DSDTSE, is a good start. First, it has built into it MOST of the hacks which a DSDT will need for Snow Leopard support. Second, it DOES NOT do all the 'usual suspect' device renaming, so there is still a requirement for DSDTSE. Or, of you're like me and like to do DSDTs by hand, then DSDTSE is still the 'go to' application.
Finally, DSDTFixer is just as dumb as DSDTSE is, in that it can only extract the RUNNING DSDT (and as we all know, Snow Leopard can only run with a heavily hacked DSDT, not an original one). It CANNOT extract the BIOS's DSDT, nor could DSDTSE. However, DSDTFixer has an option which DSDTSE does NOT have. A drag and drop DSDT feature. Let's say you have already extracted your mobo's BIOS's DSDT using Ubuntu, which is the sure-fire method. You would then launch DSDTFixer and then drag and drop the Ubuntu-extracted DSDT.
Cat /proc/acpi/dsdt /home/ubuntu/Desktop/-dsdt.aml. Into the DSDTFixer window, and then invoke the 'Hack It!' Option, or whatever you choose (there are a number of check boxes, some of which are not applicable to all mobos), and the result is a 'fixed' DSDT, one which SHOULD be operable for Snow Leopard. One surprise is the sound device remains as-is, and is not renamed HDEF. It will be AZAL if it was originally named AZAL, and it will be AC97 or MC97 if it was originally named AC97 or MC97. Another surprise is the PWRB device is not hacked to change HID to CID, for power button support. Oh, well, it STILL is quite useful, and appears to be a very good start, particularly as it has a 'drag and drop' feature, which most previously available DSDT editing tools were lacking.
Also, the included documentation describes in detail every change which the tool is presently capable of making. DSDTFixer 1.2.2. Highly recommended! And, an English-language version IS available (the developer's site is usually in Spanish).
Mosslack 7/4/2011, 13:04 น. This new tool, from the same team which produced DSDTSE, is a good start. First, it has built into it MOST of the hacks which a DSDT will need for Snow Leopard support. Second, it DOES NOT do all the 'usual suspect' device renaming, so there is still a requirement for DSDTSE. Or, of you're like me and like to do DSDTs by hand, then DSDTSE is still the 'go to' application.
Finally, DSDTFixer is just as dumb as DSDTSE is, in that it can only extract the RUNNING DSDT (and as we all know, Snow Leopard can only run with a heavily hacked DSDT, not an original one). It CANNOT extract the BIOS's DSDT, nor could DSDTSE.
However, DSDTFixer has an option which DSDTSE does NOT have. A drag and drop DSDT feature. Let's say you have already extracted your mobo's BIOS's DSDT using Ubuntu, which is the sure-fire method.
You would then launch DSDTFixer and then drag and drop the Ubuntu-extracted DSDT. Cat /proc/acpi/dsdt /home/ubuntu/Desktop/-dsdt.aml.
Into the DSDTFixer window, and then invoke the 'Hack It!' Option, or whatever you choose (there are a number of check boxes, some of which are not applicable to all mobos), and the result is a 'fixed' DSDT, one which SHOULD be operable for Snow Leopard. One surprise is the sound device remains as-is, and is not renamed HDEF. It will be AZAL if it was originally named AZAL, and it will be AC97 or MC97 if it was originally named AC97 or MC97. Another surprise is the PWRB device is not hacked to change HID to CID, for power button support.
Oh, well, it STILL is quite useful, and appears to be a very good start, particularly as it has a 'drag and drop' feature, which most previously available DSDT editing tools were lacking. Also, the included documentation describes in detail every change which the tool is presently capable of making. DSDTFixer 1.2.2.
Dsdt Fixer For Mac Download
Highly recommended! And, an English-language version IS available (the developer's site is usually in Spanish). Interesting.
How does this program differ from using the hacks within DSDTSE? Are they applied automatically where DSDTSE requires one to actually copy the code over from the database of fixes? Well, it has a menu where you check the boxes (you can check all of them, and it will subsequently tell you that that fix was not needed) and then you click the 'Hack It!' The code required is contained within a file.
No reason to bother reading that file, although it could be instructive, to some. The hacks which cab be automagically applied are MUCH more than DSDTSE supports by its samples. All kinds of variations, too, not just T0 and T1, but a great many similar ones. Mosslack 7/4/2011, 16:35 น.
A final point: DSDTFixer cannot (and won't) fix something that is not there in the first place. Meaning, if the original, unmodified DSDT does not have a sound device, then it will not put one in for you.
And, as I mentioned, the device names are not changed at all, so you will be left with AMI-like or Award-like (or whomever-like) device names and certainly not the preferred ones. For this purpose, DSDTSE is still needed, and it helps to have a crib sheet which lists all the usual device addresses and their usual names. Jeff 12/4/2011, 14:29 น. Something happened because now when I choose Shutdown on the menu Mac OS X appears to be shutting down (no kernel panic) and the screen goes dark but the computer stays on. It used to power all the way down. Another strange thing, about half the time when it comes up the mouse is very messed up.
Its moves extremely, extremely fast and in the opposite direction. Moving the mouse down the pointer moves up and vice versa. After a reboot or two it works as it should.
Any suggestions on what the two problems might be related to?