Omicron

The closest thing I see in the thread you linked is the GDC Beast M2 to "external cable" connector (not really a M2 to port.) The BPlus unit comes as a whole device which cannot really be "deattached" unless you remove the M2 end from the computer itself. I wonder why no one is interested in OCuLink, I guess it's just too niche of an option. Would be nice to have a standardized no-latency, no Thunderbutt dedicated PCI-E port on laptops, but that's just too much to ask I guess...

While everyone is all preoccupied with Thunderbolt, I came across a pure external PCI-E standard that directly lets you connect 4x or 8x PCI-E lanes via a cable (with none of that extra nonsense like USB-C or Displayport communication over the same port.) Like ExpressCard, it sounds hotswappable as well. Only problem is, it seems like no one knows about this outside of niche server applications (Supermicro as one example.) How come everyone went for the Thunderbutt route over OCuLink for eGPUs? For those who are a bit creative, I could see retrofitting a laptop with a 4x M2 slot with a card that lets you route the lanes to a OCuLink port you cut out and install on the side of a laptop, and connecting that to an OCuLink eGPU enclosure. (Something with a bit of CPU grunt like the Clevo N650DU.) Anyone else been looking at this?

Thank you, this is what I expected reading through some of the other threads (I just wasn't able to really get a confirmation.) That's fairly unfortunate. Some of the T430s'es have Thunderbolt 1 on them (which has 2 x 10Gbps lines from what I am reading, but you can only use 1 of those per "device.") Therefore, the Thunderbolt 10Gbps link should be similar to a PCI-e 2.0 2x link (and would then no longer have the Nvidia compression enabled.) Not sure if the newer Thunderbolt enclosures (made for Thunderbolt 3.0) are really comparable with this first generation though, and there are only a few subpar solutions available that work with the Thunderbolt 1.0 link.

Does anyone know if the T530 or T430 run a 1x Pci-e 3.0 link when an ExpressCard eGPU solution is used (like the PE4C V3.0 is used?) Or does it still run at 2.0 speeds? There should be 16x 3.0 lanes available on the CPU dies of Ivy Bridge mobile processors as they are just the desktop processors, but I am not sure if Lenovo wired the ExpressCard slot to this or the slower 2.0 lanes provided by the chipset.

Okay, this tweak definitely depends on the compiler you are using. The 2016 Intel AML compiler generates these buffer objects that seem to be defined constants in an array. This is normally named "ToPLD()," and is passed in instead of the older Buffer() functions instead. Therefore, I succeeded by first finding a 2012 copy of DSDTEditor which has IASL within the same directory. I also used the Version 4.0 of the Windows ASL program: http://olarila.com/dsdt/DSDTEditor_Linux_Windows.zip http://download.microsoft.com/download/2/c/1/2c16c7e0-96c1-40f5-81fc-3e4bf7b65496/microsoft_asl_compiler-v4-0-0.msi I used the interface of DSDTEditor to dump the DSDT info, and then did a test compile on the resulting decompiled .dsl file. Viola, same errors, but these were the older style and both were simply corrected by pressing "Fix Errors." The first item was fixed as defined above, and now I actually has Buffer() functions which were simply replaced with Package() functions instead. I then plopped the QWord code within the appropriate section, and compiled it again. Then, I used the Windows ASL program to override the existing info, and rebooted. Finally, it works! However, I then installed the express card adapter, restarted, and then was hit again with the ACPI blue screen issue. Therefore, it seems like the ACPI info I patched was specific only to current devices installed, and once the BIOS adds the GPU in, Windows no longer works with the other patched ACPI info. If I remove the card and reboot (with last safe configuration,) I get back into Windows no issue with the device manager as shown above. Maybe there is an issue with installing something like a GTX 770 (such as the 2GB of memory on it that needs to be mapped?) So close... Update: I finally got it working. You absolutely cannot boot up with the GPU attached as this always causes ACPI bluescreens. However, while I also had issues with hotplugging at first, I figured it out. Initially, when I plugged the Expresscard in when in Windows, it would just sit there with the fan at full blast, and no GPU detected anywhere. Some posts mentioned vague yammering of a missing 3.3v connection, but as I had an ATX PSU installed (Seasonic SS-600ET,) this didn't make much sense at all as the ATX connector went right to the PSU. However, I hotplugged it in another time, and then proceeded to unplug a fan going to the PSU. It went off completely. This seemed odd to me, and almost seemed like the PSU didn't have enough load on it (or the boot sequence wasn't properly initialized for the ATX standard.) Therefore, I just overrode the power on jumper on the P4C, and attached it to the computer even though the fan was running on full blast. It was detected instantly (so it seems like these PSUs need to be initially started, and have some sort of extra load afterwards or an "ATX initialization code.") Now my T420 has a GTX 770 that is hotpluggable (which is great,) but still no go for a BIOS to Windows cold boot with it installed. The link seems to be at 2.0 1x, but still not sure if this has compression enabled.

Alright, this is fairly frustrating. I am attempting to patch my Windows 7 x64 install using this guide so that my GTX 770 eGPU will work with it. I have followed this guide up to editing the dsdt.dsl, adding in the QWORD in the appropriate section, calling iasl, and patching it. Initially, I attempted to compile the modified dsdt.dsl and was hit with two errors: "Name (_IRC, 0x00) // _IRC: Inrush Current, Error 6103" "(_PLD: found Buffer, Package Required), Error 6105" I was able to fix the first error by changing the line to: "Method (_IRC, 0, NotSerialized) { Return(0x00) }" However, it is the second error that is really annoying. After researching this "Package Required," I found a patch which appears to encapsulate similar looking sections with the function "Package(){}." This seemingly makes sense as the Package function should "cast" the Buffer object into a Package. Therefore, I went through the dsdt.dsl code and placed the offending buffer returns within the curly brackets of Package (like Package(){DATA}) Afterwards, it compiled without a single issue. However, I patch it using asl, and I am simply hit with a BSOD for invalid ACPI configuration (obviously meaning Windows did not like patch.) Attached are the two files with the appropriate modifications. I'd like to keep using this T420, but if this doesn't work, I probably should just invest in a desktop... dsdt.zip