Hervé

I don't know; but on occasion, I have a kinda similar delay with my E6440, just longer (like 3 or 4 mins). But the screen does wake eventually.

It seems you read wrong, no such thing in your plist as a Find key set to false... The value of a key is placed underneath, not above.

The answer is in the question, isn't it?

PCI ven/dev id 2001:3310 is listed as DLink DWA-123 Wireless N 150 adapter in revision D1. The best I find for this is this. There are clearly at least 3 x different hardware versions of the DWA-123: A1, B1 and D1. For revision D1 model, the above URL lists driver RTLWlanU_MacOS10.9_MacOS10.12_Driver_1830.20.b7_1827.4.b27_UI_5.0.6.b4. I've had a look at it with Pacifist and the kext called RtWlanU covers your DWA-123: its Info.plist file contains the following entry, which matches: <key>DLink_DWA123_88EU</key> <dict> <key>CFBundleIdentifier</key> <string>com.realtek.driver.RtWlanU</string> <key>IOClass</key> <string>RtWlanU</string> <key>IOKitDebug</key> <integer>0</integer> <key>IOProviderClass</key> <string>IOUSBInterface</string> <key>bConfigurationValue</key> <integer>1</integer> <key>bInterfaceNumber</key> <integer>0</integer> <key>idProduct</key> <integer>13072</integer> <key>idVendor</key> <integer>8193</integer> </dict> As far as ids are concerned: 0x2001 = 8193 0x3110 = 13072 The Sierra driver can be expected to work in High Sierra, as stated here. If not, try Chris1111's tweaked package. It says it supports "DLink_DWA123_88EU" It seems the chipset for that dongle would be Realtek's RTL8188EU. NB: All this was found with a little Google search effort...

OS X/macOS is more graphics hungry and battery will last less than under windows. If you disable Tubo boost when running on battery, yes you will save some battery life to the cost of performance...

By the way, make sure you don't have a duff connection when you attach your E7440 to your PR03X. I've just noticed that mine was not working properly if I simply hooked my E6440 down on the docking station: the On/Off + Eject buttons of the docking station often did no lit up in blue. I guess the angle between the laptop and the docking station connector caused the issue and I had to lift up the front of the laptop for the connection to work properly. Without a good connection, no DVI output...

Ok, I went back into El Capitan 10.11.6 Build 15G18013 (which I had not done for some time) and applied the Security Upgrade 2018-0004 10.11.6. Once I rebooted into 10.11.6 Build 15G22010, I noticed an updated Azul framebuffer kext v10.14.74. I patched this for my usual HDMI + DVI settings (patched kext in /S/L/E for a change), repaired permissions, rebuild cache and rebooted. On reboot, no issue, DVI is fully operational off the K07A (PR03X) docking station on port #7 with connector-type 00020000: As far as I'm concerned, your patch is therefore erroneous and you should be using: 03061200 00020000 87000000 not 02041200 00020000 87000000 Just in case, I've tried again to patch port #6 with DVI connector and it does not work. So, I believe your above patch will never work, unless things are different with HD4400 on the E7440, but I somehow doubt it.

No sign of codec... Try and install VoodooHDA + AppleHDADisabler, then look again in DPCIManager.

Elementary my dear Watson ! http://www.cpu-world.com/CPUs/Core_i5/Intel-Core i5-4200U Mobile processor.html 2.6GHz is the max. Turbo boost frequency: https://ark.intel.com/products/75459/Intel-Core-i5-4200U-Processor-3M-Cache-up-to-2_60-GHz Obviously disabling Turbo boost when running on battery was not going to help, was it? You gotta learn to do a little research about your own hardware...

Like a very brief "Shrreeeeeek"? My E6440 does that too on restart, right when the system shuts down. Nothing you can do about it afaik.

As far as I can see, 10.11.6 last Azul framebuffer carries version 10.14.73. The layout 0x0a260006 is coded follows: 0600260A 01030303 00000002 00003001 00006000 00000060 D90A0000 D90A0000 00000000 00000000 00000800 02000000 30000000 // port #0, LVDS 01050900 00040000 87000000 // port #5, DP 02040900 00040000 87000000 // port #6, DP FF000000 01000000 40000000 0F000000 01010000 04000000 00000000 0E000000 00000000 So, same code as before...

There's only one GUID (aka GPT)... Go for that, that's the recommended partition scheme.

How did you actually patch the Azul framebuffer kext? I wouldn't recommend mixing direct kext binary patching with Clover on-the-fly patching for instance. That's likely to cause issues. Do either/or. The patches I detailed should definitely work under OS X El Capitan; as long as patching is done properly of course... I suggest you do one of the following (but not mix them): apply your Azul binary patches in Clover (on-the-fly facility) apply your Azul binary patches to a copy of the kext that you'll save in /L/E with a version increased to say 999 in order to supersede the vanilla kext in /S/L/E. This being said, my tests were conducted with an E6440 using an E-Port Plus docking station: I'll verify the behaviour with an E-Port I have at home and will let you know but, from memory, it worked just the same. It's the small K07A model with USB3.0 ports: As far as I can see, it is entirely identical to what people often refer to as PR03X.

You'll have to explain -in details- what you did; the exact steps. "I use old Clover Efi but don't work" ain't good enough...

If all you've done is change the HDD/SSD, I don't see why you're asking to re-patch the BIOS tables. Just re-use all that you had on your previous disk: install the same version of Clover on your new disk, then import the Clover EFI folder of your old drive on the new one. In the EFI partition, of course! You could have also made a backup or a clone or your 1st installation and restored it to the new disk.

If you cannot see the dongle in the USB section of your SysProfiler, then it's a USB port issue.

@Pippo BalestrieriThis thread has long been dead; it's been 5 years since the OP wrote his single post and visited the forum. Do not expect a response. For what it's worth, back then, ML would have most likely been installed with the myHack tool that we advocated and supported at the time. There are several models and generations of a ThinkPad Helix. OP's model was clearly an Ivy Bridge/HD 4000 one. Open up a new thread with your own model's specifications and we'll see what we can do, preferably with current macOS High Sierra (really no point considering obsolete ML in 2018). This old and dead thread will now be closed and archived.

Try it!

No, one or the other. That's what "try EAPDFix kext instead" meant.

Make sure you have the latest version of the kext. Then you could also try EAPDFix kext instead.

Graphics not initialising...

Well-known bug: double press required to get out of Caps mode. You can look that up.

Added DW1820A combo Wifi ac/BT4.1 NGFF M.2 card. /!\ Caution: do not confuse with DW1820 which is incompatible!

There seems to be some confusion on this card (or I should say these cards), so let's try and clarify the matter. There are actually 2 x cards: a DW1820 and a DW1820A. The difference may be subtle but essential nevertheless... DW1820 is based on Qualcomm chipset QCA6174A. It carries PCI id 168c:003e. It's unsupported as specified in our inventory list. DW1820A is based on Broadcom BCM4350 (see wikidevi link above). That card carries PCI id 14e4:43a3. It should be supported OOB. DW1820: DW1820A: -> I've updated the wireless inventory accordingly.

Got an opportunity to obtain a very cheap motherboard with an [email protected] (boost to 3.7GHz). Straight replacement as expected, all I had to do was generate a new CPU PM ssdt. Nothing further. GeekBench score on the up of course: