sbp

Yes, I know that this is a forum dedicated to versions 2.x, and this is a question about 1.0 and 1.1. But I don't see any place more appropriate to ask, and I'm a bit desparate. I attach to this post the schematic of Pe4C v1.2. Please look at jumper TP5. My problem is that my eGPU card is just not being recognized, at all. I can't imagine any other problem than insufficient power. (The card does not appear in the Device manager, no matter what I do). Is it possible that shorting this TP5 jumper will solve my problems??? (because it will deliver 3.3v to the card?) I see nothing anywhere in any documentatioin about why/when one might use the jumper, but perhaps this is the reason it's there? I really have no experience with hardware and I don't want to fry anything -- sO i'd like to ask people if 1) there's a chance that shorting this jumper will get the power i need to my card? and 2) can I try it with impunity? or is likely/possible that I'll fry my card if I do. Set up ois a Lenovo T420, Asus GeForce 760, PE4C-PM3N, pulse 700W power supply thanks! PM3N_schemaitc ver12.pdf

I'm sorry to say that I think my eGPU project is about to end in complete failure. Here is my "last resort": Thinkpad T420 model 4178-AFU (within Intel HD Graphics 3000 iGPU and no dGPU), running Windows 8.1 Pro and 16GB RAM. PE4C 12 and PM3N 1.1 Asus GeForce GTX 760 Pulse Switching Power Supplly Model PPS-700BR. The problem is very simple to describe: the card is simply never detected, ever, by anything. It does not show up in Windows Device Manager at all. The card appears to be running just fine: LEDs light, the fans turn. But there is no sign of life in Windwos Device Manager, so game over before it has begun. En route to this sorry state, however, the following happened: 1. Filrst, I tried to install the mPCI-E card into the WWAN slot, and nothing happened. Then I realized from this forum that I had to use the (Less accessible) WLAN slot. At first, the laptop put up a warning that the card was an unauthorized Wifi card and halted. So I found a modified latest-version BIOS from the BIOS Mods forum. The modified BIOS had no whitelist. This seemed to work perfectly: when I would hot-swap the card with the live Wifi card when the Windows Logo appeared, it showed up beautifully in device manager. unfortunately, of course, so did Error 12. I managed to do the DSDT override, or at least I think I did: thee is the "Large Memory" entry in the Device Manager. I seemed to have the right drivers installed, the device manger showed the card as working properly -- but no image ever appeared from the card to any external monitor. There were all sorts of suggestions that I need to be careful to set in the BIOS that the primary display is on the PCI-E bus -- but there is absolutely Ntohing in the Thinkpad BIOS about such a setting. (there is the BIOS of T420s that have a dGPU, but this one doesn't). I can only say that at this point, IO have cleaned out all the drivers (at one point I had only the basic Windows drivers, not even the Intel HD Graphics 3000 drivers), I have cleared pout the DSDT override, and I have reflashed the stock BIOS. I have even taken out the CMOS battery for a few hours. The board just does not appear.in Device Manager. There is one thing that makes me think that perhaps I have corrupted something in an unknown way: I am quite sure that I have reflashed the stock BIOS correctly. However, when I boot up with the eGPU attached, the system does not complain and halt like it used to -- it seems to just boot up with no trouble. WHen it does this, the device manager lists that mPCIe port as empty of course. Is it possible for me to have correctly flashed the stock BIOS but not have the system halt when a eGPU is booted with the machine? Anyway, thanks to all who provided support, and if you have any clever suggestions, certainly I am open to them.

I hope that this is the right place to post this question: In the now-closed "Implementations Hub" thread there is the following assertion: (the last word "here" is a link to an old post about the fact that later Thinkpad BIOS change the memory map so that TOLUD=3.5) I am **horribly** confused by the assertion that these systems are incapable of having 3.5GB of RAM followed by the assertion that they will work with DSDT Override. Which of the following things is actually true about my THinkpad T420: 1. With more than 4GB of RAM, and a DSDT Override, the T420 should work EVEN WITH a BIOS version 1.15 or later. or 2. With more than 4GB of RAM, and a DSDT Overrise, the T420 STILL MUST HAVE A BIOS version 1.14 or earlier to work. If assertion 1 is correct, please correct the (now erroneous) assertion in the "Implementations hub"? If assertion 2 is correct, please explain. Thanks!! i thought the whole point of the DSDT override was to make it irrelevant how much ram there is in the system.

>Incidentally, the "four tiny holes labeled 3v, 5v, 12v, GND" are test points useful to do circuit board power validity checks with a multimeter Drat. But thank you for being so informative. It might be impossible to answer the following question, but just in case: The Asus GTX 760 ships with a small cable adapter which is sort of a "Y"--connector: well, really a "V" connector I guess, where the bottom point of the "V" is an ATX 8-pin CPU connector, the two sides of the "V" are cables, and each of the two top points of the "V" are an ATX 6-pin CPU connector (I am describing the connectors according to what I just learned from you answer above).. In my set-up, the ATX 8-pin connector plugs into the eGPU, and *one* of the ATX 6-pin connectors is connected to a matching power cable from the PSU. The other ATX 6-pin CPU connector is left unattached and dangling. There just insn't anything ovbvious I could attach it to. There are two ATX 4-pin CPU connector among the various cables that emerge as not needed, coming out of the exercise. I wasn't meant to attach one of the unused ATX 4-pin CPU connectors to rhe unused 6-pin connector on the adapter cable, was I??

The same is not true for my high-TOLUD Thinkpad T420, is it? I have the model with no dGPU, only an iGPU -- and/but I still need to hot-swap, don't I? (Because I have to wait for the DSDT override before I bring up the eGPU to avoid a BSOD (apologies for all the FLAs ) Hmm, perhaps situations where your PCI compaction+defrag is sufficient don't have this problem, since the compaction+defrag happens before the card is first initialized

OMG I'll bet this has been my problem all along with getting my Asus NVidia GeForce GTX 760 card detected. I am using the PE4C v.1.2 with PM3Nv.1.1. I got the earliest versions because everything did seem expensive and I thought they were functionally equivalent, but now I understand that the higher models have a CLKRUN delay switch, so I could avoid the hot-swap entirely. (I have a THInkpad T420 with a modified BIOS without the WL). So far, the card has been detected about 5-10 times out of the 500,000 times it feels like I've tried to get this going. Please forgive the following display of inexperience -- but perhaps Devster and Antraz would kindly post a few close-up pics of the power connections they have going between the PSU, the adapter, and the eGPU? The power supply I bought from a local retailer seemed to have a plug that fit the "ATX-24PIN power" socket, and also one that fit the "Floppy 4-pin" socket. So I connected those. Also, the card has an 8-pin socket, and also came with a cable that has one 8-pin socket and two 6-pin sockets. The power supply had only one of the 6pin plugs, so I plugged the 6-pin PSU plug into one of the two 6-pin sockets on the adapter cable, and plugged the 8-pin plug on that adapter cable to the 8-pin socket of the GTX 760. The second 6-pin plug of the adapter cable is not connected to anything. Is that a problem? Finally, I realized afterwards that there seems to be **another** socket that needs power of that adapter... but there's nothing on the PSU which fits it, I believe. I have attached two pics of my adapter. the socket with no power is the one next to the switch, with four tiny holes labeled 3v, 5v, 12v, GND. Is this what you called the "4-pin CPU cable"? I will post the exact model of power-supply when I get home tonight. In the meantime, perhaps you could post a few close-ups of the adapter all connected up, and also one showing the cabling to the GPU itself. Thanks so much scott

There is an old post in NBR which asserts (even "explains") that/why one needs to downgrade the BIOS to 1.15 or earlier in order to have any chance of success with a Thinkpad 420. Could I ask for confirmation please that this is no longer true? The explanation in the earlier post was that the BIOS itself enforced TOLUD=3.5 or greater. This might have been a deal killer before, but with DSDT Override it is no longer a problem. Correct? 2. Next "problem" with using stock current T420 BIOS would be the whitelist (If you're using the mPCIe slot). In various places there is an assertion that to get around the whitelist, you "MUST" either use setup 1.x or do a hotswap with a supported Wifi card. (i.e.. start the machine with the Wificard in the slot, and carefully swap the card after the BIOS has finished loading). Again, please check my understanding: this whitelist business is not a big deal anymore, because it's easy to find modded BIOS without the whitelist, which are otherwise identical to the stock BIOS. correct? 3. Next, there seems to be some issue around the CLKRUN signal. This is a bit obscure, but my understanding is that that at present, both the hotswap method and using setup 1.x work around this problem as well. Correct?? however, unfortunately: 4. Using F12 to conveniently pause the boot after the BIOS has loaded, to give us time to hotswap the cards, causes at BSOD a few moments later, just after the Windows logo appears. So it's not enough to wait for the BIOS to load. My understanding is that when the Windows logo appears is exactly when DSDT is loaded -- and I"m sure we all remember the fun we had mucking about with the DSDT to create the 36-bit space that would enable the eGPU to actually be loaded. So it makes sense that if the eGPU is loaded **BEFORE** that modified-DSDT gets loaded, then the eGPU will have to take the regular 32-bit bus, instead of the nice spacious 36-bit bus that will be in service after the modified DSDT loads. Question: is there some reason that it's important that this swap happens as early as possible? tt's very fiddly and a PITA to have to get it "just right." Can we just boot into the desktop with the Wiifi card in and then when start-up is all over, hot-swap the Wifi card with the mPCI-e adapter. My hope is that when I do this, the laptop will just immediately switch over to the graphic card and external monitor. Is there some reason why it's important that the eGPU needs to load BEFORE windows starts graphics? (If this seems like a strange question, or an academic one: my problem right now is that my eGPU card is just not being detected at all. It doesn't even appear in Device Manager. It turns out that there are endless threads about this problem in the NVidia Forums dedicated my card -- ordinary installations see the same problem. I'm trying to understand if I really only have a split-second window to make this setup work. Or if I can relax about when the hotswap happens. Thanks!! )

It works on my T420 also. Just make certain that you are booting MBR and not UEFI, and also that TESTSIGNING is ON (as mentioned in the original post).

<!-- google_ad_section_end -->Certainly part of my problem was related to MBR vs. GPT mode, though I think that what I did was stupider and more damage-inducing. I had switched to GPT at some point early on in the process in order to follow the post of someone who said that they had got a T430 to work without any DST override. When that didn't really pan out, I reset things, but that annoying "test mode" watermark stayed on my screen, despite the fact that I had reset to TESTSIGNING OFF. So I asked on eightforum.com how to fix this, and it seemed that my choices were either 1. to check by hand every individual driver loaded (because turning TESTSIGNING back to No apparently only disallows new unsigned drivers from loading; drivers that were part of a previously known good configuration will continue to load, and you'll continue to be in "test mode"), or 2. use system restore. I never really trust system restore, basically because it's made by the same sloppy company whose sloppiness is usually the reason that I need to restore my system, so I never really just get back what I had, I just get "a lot" of things back -- i.e. more mess. But a quick run through Device Manager revealed not a single unsigned driver (though I wonder if some of the drivers which are marked as signed just by "Microsoft Windows" include exactly the unsigned drivers that now load -- did I mention that I find things a bit sloppy in this OS?), so I went for system restore. Remember, this was only to remove the "test mode" watermark. Much to my horror, System Restore failed, and left me with a machine that BlueScreens just after the Windows Logo. That's when I remembered with even more horror that I was probably choosing to return to a restore point that was set at a time when boot was MBR, but the BIOS was now set to UEFI only!! Yes, I freely admit that I'm an idiot, but surely the result of applying System Restore to a machine in perfect health with a watermark problem should not be an Blue Brick. Fortunately, setting the BIOS back to "Legacy, then UEFI" boot order and clearing out any residual mess about DSDT in the registry got me back to a watermark-less and booting machine. I then tried again to do it purely according to Nando's post with QWordMemory, but I went insane trying to get the resulting .dsl file to compile without errors. And every time I was able to do this, the resulting machine would bluescreen just after the logo appeared. That's when I understood artearte's wonderful suggestion for keeping things clean by using the QWordMemory stuff and iasl and .dsl to produce the organ to be transplanted ONLY (i.e.. the _CRS table), but to do the actual operation in a more pristine environment (using only asl and the .asl format). Sure enough, this "just worked". I'll let nando and the other experts here decide, but with great uncertainty I humbly suggest (nothing more than that, I am **very** new to this and almost lost the machine) that the DSDT override post should be amended to the "combination" method (i.e. use acpidump and QWordMemory and iasl to produce the expanded table inside an .asl file, then separately use "asl /tab=DSDT" to produce the .asl that you actually modify with that expanded table), along with a suggestion to use one of the two DSDT Editors rather than notepad (there is an excellent discussion of this repulsive subject here. I think it's true that if I had used the two different editors available I could have produced a clean DSDT, and I'm curious to know what I might be able to tweak as a result. But for now I wanna get this GPU to work). Whether my problem was bad dsdt editing or switching back-and-forth between MBR and GPT or a combination of the two I'll never know, but I'm sure you're right that MBR/GPT issues were central. In any case, a random combination of DSDT changes, MBR/GPT swaps, and System Restores is unlikely to produce order. I've learned my lesson -- and get to keep the T420 as a souvenir. - - - Updated - - - It works on my T420 also. Just make certain that you are booting MBR and not UEFI, and also that TESTSIGNING is ON (as mentioned in the original post).

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. grrrrrrrrrrrrrrrrrrrr. 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 Load a hive into the registry: Core Services). 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 know that you posted this some time ago, but I hope you might remember a few details which might be the difference between success and failure for me. My set-up is both similar and different: Lenovo Thinkpad T420 (4178-AFU); i7-2620M; 16GB RAM; no "dGPU"; iGPU = Intel HD3000; Windows 8.1 Pro. My questions refer to your procedure: Now for the fun part........ Disconnect your eGPU ...[post continues for some time] So: 1. The above chunk begins with "Disconnect your GPU until I say so" and ends with "Disconnect your eGPU.". Of course it is not possible to do both. Did you intend that this ENTIRE set of instructions would be done with no eGPU? In particular, does one see the 36-bit big memory just by mucking about with software? Or in addition to the DSDT stuff, do I need to connect the eGPU in order for the system to actually reach up and make an allocation in 36-bit space? 2. According to the original post, in addition to what you write, one MUST turn TESTSIGNING ON in the bcd. (via bcdedit -set TESTSIGNING ON). Did you skip this step and things worked? or did you have to do, and just forgot to mention it? 3. Would SOMEONE be able to tell me if this works with both MBR and GPT installations? Does it work with both legacy and UEFI boot? WHile I'm on this subject, I am exceedingly confused about this "secure boot" business -- how do I turn it off on a T420? At this point, I would rather just run in legacy mode without UEFI in order to be CERTAIN that this is not the issue. (right now, I get a BSOD when the DSDT loads). 4. May I replace the asl.exe and the iasl.exe included here with the newest versions? Is that a particularly good or bad thing to do? I can follow all the various variations of instructions -- and arrive at a DSDT compilation without errors. But after the reboot, I get the solid-blue windows 8.1 logo to appear (which I understand means that DSDT is being loaded) --- and BAM! BSOD time. The only recover I have found possible is to boot from installation media, and go back and do some simple surgery on the C drive to rid the registry there of its DSDT override. Could I have some sort of "secure boot" which prevents the DSDT override and blue-screens? How would I turn it off if I did? Nothing says "secure boot" in the BIOS. Alternatively, perhaps I should be using the latest versions of asl and iasl. But if I don't use the DSDTEditor, I don't see how to fix the myriad errors that show up in compilation. Does anyone else have this error on lines like Name(_PLD, ToPLD(...)...) -- where the error is something like "uses Buffer but requires Package" and I don't see the word Buffer anywhere near this code. (I also don't see the definition of ToPLD anywhere. perhaps someone could clue me in. This is getting really a bit tiresome. Any answers appreciated.

I am finally able to continue after a week of being away. I have made some considerable progress, but am stuck once again: Some things I've learned about my Lenovo T420 (4178-AFU): 1. I transferred the WLAN cad to the so-called mPCI-e.... and it does not start up. The WWAN slot does **NOT** seem to be a live mPCI-e slot. The only cards supported on this white-listed slot are some mSATA hard-drives and some WWAN cards. My guess is that none of the whitelisted cards for this slot are mPCI-e. This is rather annoying, because the "other" mPCI-e slot (in fact, the only one) is underneath the keyboard, and in addition it holds the Wifi card. If you're curious as to why I don't just use the Express Card slot, it's because I have a USB 3.0 card there already. Before I spend more money on a different set-up, I would like to try to make what I have work. To start, I have flashed a copy of the latest BIOS (1.46) modded to have no whitelist. , and I would like to use the mPCI-e slot underneath the keyboard. I have 16GB of RAM in the machine, so TOLUD will be a problem. 1. If I insert the mPCI-e card of the ada[pter into the WLAN slot, turn on the card, and then after a few moments, turn on the PC, the machine beeps a fair amount, goes thorough TWO reboot cycles, but in the end the machine appears to boot, and the GTX is seen, and the driver appears to be correctly installed & configured. -- The driver looks like it's happy. No exclamation points. Only trouble is: There is nothing seen on any video monitor attached to the card, and I can't even bone singring up the NVIdia console, -- when I try to bring it up, I get a message like "You are not using any thing from the NVivida hardware:" But it looks like it SHOULD work -- for example, there is PCI bus memory allocated to the card. 2. On the other hand, if I do as I was told, and start the machine with the WLAN card in the slot, pause the boot-sequence, then switch WLAN card for the MPCIe of the adapter, then without fail, the card is recognized, but the driver has an exclamation point because of Error 12. I have tried to do the DSDT override, but I am finding myself unable to get past one last error in the DSDT dsl file. The error that is left is "Error 6126 - syntax error, unexpected PARSEOP_DEVICE, expecting $end and premature End-of-file." Until I can avoid getting any errors, I can not complete the next step of the DSDT procedure. Has anyone got a dsdt.dsl file for a Thinkpad T 420 tht is known to be error-free, that they could share? Is it possible that when it "looks" like the card is properly resourced and the drivers are happy -- that actually the card IS happy? What would I do to get video to flow to my external monitors? If I can fix that one syntax error, I should be able to do the dsdt override I need to get access to 36-bits of space on the bus, Thanks for any help with that error. One final question: where do I go to retrieve my copy of setup 1.3, now that I've made a donation? I'm not positive that it will help, but I'd like to try the compaction that seems to offer. I've paid as I should, but have no idea where to go next. Thanks! scott

>Can you relocate your WIFI card into the WWAN slot and get it detected in Device Manager? 1. Very clever, did not think of that. Just to make sure I understand: I should not expect the WLAN card to actually work in this set-up, because I haven't covered pin 20, so I'll have a Wifi card with a dead radio. But a radio-disabled Wifi card is still mPCI-e. On the other hand, a WWAN card is a modem and needs nothing more than a serial port. In fact, that WWAN slot is advertised as supporting (some whitelisted set of) WWAN cards and mSATA drives. so perhaps that's enough already to know it doesn't do "real" PCIe. 2. Actually, I had of course already tried putting the mPCIe adapter card into the WLAN slot -- but I didn't appreciate that I have to start the boot with WLAN card and then before I select the boot medium I switch WLAN for the adapter card. Before, I had been starting the laptop with the WWAN slot empty and then *carefully* hotpluging the card. Unfortunately because of work demands I might have to leave this for as much as a week. (I'll be away). What a cliff hanger (for me anyway). Thanks for the help, once again. I will report back as soon as I can try these things.

Well, according to the Lenovo documentation the WWAN slot is also a mini-PCI-Express slot. That being said, I learned in this forum that even though both slots are mini-PCI-e, they are not compatible: to use a WLAN card in the WWAN slot, one must mask ping 20, because the WWAN card needs that signal, while if that signal is set then the WLAN card will kill its radio. I understand that with a GPU, the signal to worry about is CLKRUN.Is it possible that the WWAN mini-PCI-e slot of the Thinkpad T420 **never** provides this CLKRUN signal? One other straw I might grasp at: The slot is a "full length" mini-PCI-e slot, but the card shipped to me with the PE4C adapter is a **half-length" mini-PCI-e card. Now I taped it down, so I believe the contacts are making contact. But the hole in one back corner does not mate with the little connector 'bump' on the motherboard; nor does the screw at the other corner screw into any hole. Is it possible that in order for the card to get power at, these two connectors must be properly connected? I suppose there must exist adapters which can turn a half-length card into a full-length card. Is it neccesary to get one of these in order for the card to work at all? As far as the whitelist is concerned: I have by now replaced the BIOS 1.46 (latest) with one with the whitelist removed. Thank you for your help so far. scott

I was so hopeful when I read your post, because I think it MUST be something equally banal. The "gold fingers" you mention is just the length of the PCI-Express connector , right? As far as I can tell, there is nothing covering the gold PCI-E connector tab. I'm working through the Troubleshooting FAQ; wish me luck. I'm "worried" about two issues: 1. Everyone seems to talk of putting the mPCI-e card into the WLAN slot. But on the T420 at least, you need to take out the keyboard to take out the WLAN card. I am using the mPCI-e slot that is underneath the laptop. It's much easier to access, just undo one screw and take off the cover. So I'm using the WWAN slot and not the WLAN slot. Is it possible that this is the cause of my problems: somehow this CLKRUN signal can't/doesn't get delivered to the GTX when one uses the WWAN slot. 2. I also worry that I seem to be the only person to have purchased the (cheap) PE4C v1.2 adapter (URL in my first post above). I thought that the differences with later models were entirely cosmetic, but upon closer reading, I think that the newer models have a jumper which can be used to set CLKRUN. Perhaps this is the problem. In any case, thanks for the suggestion; I only wish it were true. <sigh></sigh>