Hervé

Sounds like you may not have CPU power management working properly and that your DSDT requires patching

Afaik, nothing special required for those particular models, no. vPro is some Intel marketing label just like Centrino was. Consider it a set of specific security-oriented features. Apart from that, vPro CPUs remain the same as non-vPro. https://en.wikipedia.org/wiki/Intel_vPro http://www.intel.com/content/www/us/en/architecture-and-technology/vpro/vpro-technology-general.html?_ga=1.79303059.645950130.1454350102

Which version of OS X did you install? Try a more recent ACPIBatteryManager kext from Rehabman. You can Google for it.

Then you know what's left to try...

There's no sign of a Bluetooth device on your USB bus... Are you sure you have the AzureWave model with Bluetooth? There is a 943225HM (no BT) and a 943225HMB (with BT). If you're certain to have the HMB model and BT works in Windows, I'd strongly recommend you tape Pin20 as suggested by Bronxtech. Windows might be disabling BT on shutdown (taping Pin20 would keep the card fully activated). You could also try those 2 kexts in /S/L/E. They're Rehabman's work. They're also for ElCapitan, not for earlier versions but Rehabman's repo stipulates that the AzureWave BCM943225 does not normally require special FW for Bluetooth to be operational under OS X; 'should work OOB... BrcmFirmwareRepo.kext.zip BrcmPatchRAM2.kext.zip

The left side USB port is not functional OOB under El Capitan. It's the well-known USB ports problem... I have therefore revised the patched DSDT for El Capitan, with USB2.0 devices renamed from EHCx to EH0x in order to use the attached USB2.0 injector kext. The original DSDT code shows 2 x USB2.0 controllers: EHC1 @1D: 8 x ports, numbered PR11 to PR18 under hub PR01 EHC2 @1A: 6 x ports, numbered PR11 to PR16 under hub PR01 and the physical USB ports appear arranged in the following manner (as visible in IOReg when a device is plugged in the ports): EHC1 controller, port #1 (PR11) @1D11: rear port EHC1 controller, port #2 (PR12) @1D12: right-rear port EHC1 controller, port #3 (PR13) @1D13: right-front port EHC2 controller, port #2 (PR12) @1A12: left portSome hardware accessories such as integrated webcam or BT module (part of combo mini-PCIe cards) are also visible @1A15, @1D15 or @1D18. In order to regain full USB functionality, the attached USB2.0 injector (based on Info plist of vanilla AppleUSBEHCIPCI PlugIn of /S/L/E/IOUSBHostFamily kext) reflects the above arrangements with the following settings: 1 x hub PR01 attached to MacBookPro11,1-EH01 USB controller 1 x hub PR01 attached to MacBookPro11,1-EH02 USB controller All 4 x external ports are then fully functional as USB2.0 under EC 10.11. [E6440_DSDT_ElCap10.11_EHCx-patched.zip] [E6440_ElCap10.11_USB2.0_Injector.kext.zip] Edit: See below for a further USB ports update

Did you use the bootpack available here?

Duly noted about BT being enabled in BIOS. By their own very nature, you don't (can't) inject USB devices in/through DSDT. And don't confuse external USB2.0/USB3.0 ports and internal USB (sometimes 1.x) ports. I'm not sure those are working Ok for you... Can you extract an IOReg with IORegistryExplorer and post it?

Bluetooth modules of combo mini PCIe cards operate as USB devices. You don't usually need kext for them, they either work or don't, depending on the chip. Patching of vanilla Bluetooth kext can provide capability to enable/disable (turn on/off) BT (through Finder's bar icon) but that's about it. If any modification is required for Bluetooth, it's usually a firmware mod. I'm not seeing any BT reference in your SysProfiler, are you sure it's enabled in BIOS? Could be an issue with your USB ports too...

Afaik, the Toleda kext was only for Wifi. If I'm not mistaken, I think it has become kind of obsolete these days. You don't need (re)branding: wireless working is proof enough.

Unfortunately, the problem extends to Broadwell Hackintoshes too.

It was just a thought but on quickly searching the Net, I found many posts about DRM-related issues with iTunes: Ivy Bridge & Haswell Hackintoshes apparently cannot play DRM protected contents. No workaround. Posts also indicate that there would be no such issue with Sandy Bridge Hackintoshes under certain conditions... If this is true and your Lenovo falls within the above 2 categories, you can't do anything.

You probably also need to fake desktop HD4600 (id 0x0412) vs mobile HD4x00...

@GigaSonic, post us a saved output of your SysProfiler so that we have a look.

I don't know; I'd need to investigate.

In the present case, I used DSDTEditor (not MacIASL) to patch your posted file.

Please restrict your posts to lower case... You may require some additional graphics tuning for this iTunes issue... For FaceTime, make sure to have your LAN card registered an 1st interface en0, not en1 as can often be the case when the necessary driver is installed after wifi. you can check that out in SysProfiler or with Terminal command ifconfig. To fix this, remove all wifi and LAN interface from your Network PrefPane and all files from folder /Library/Preferences/SystemConfiguration, reboot then add the interfaces manually, starting by LAN. Interfaces may actually be automatically re-instated after reboot and LAN should be en0. If necessary, you'll easily identify each 'en' interface with the MAC address.

Your IO80211Family kext and its PlugIn AirPortBrcm4360 kexts are full vanilla/unmodified/unpatched. But... guess what I found in your DSDT? Device (ARPT) { Name (_ADR, Zero) [...] Method (_DSM, 4, NotSerialized) { If (LEqual (Arg2, Zero)) { Return (Buffer (One) { 0x03 }) } Return (Package (0x0E) { "AAPL,slot-name", Buffer (0x08) { "AirPort" }, "device-id", Unicode ("0"), "device_type", Buffer (0x08) { "AirPort" }, "model", Buffer (0x33) { "Atheros 9285 802.11 b/g/n Wireless Network Adapter" }, "name", "pci168c,30", "subsystem-id", Buffer (0x04) { 0x13, 0x66, 0x00, 0x00 }, "subsystem-vendor-id", Buffer (0x04) { 0xAD, 0x11, 0x00, 0x00 } }) } [...] } -> That's going to clash with your fitted Broadcom card... I'm even very surprised you actually managed to connect to a wifi network. If you looked in your SysProfiler, you would notice an Atheros 9285 wireless card reported in the Hardware->PCI section (that's just cosmetic but your DSDT injects the wrong device to OS X!). I've modified Device (ARPT) with the following patch which should fix your issues: Device (ARPT) { Name (_ADR, Zero) [...] Method (_DSM, 4, NotSerialized) { If (LEqual (Arg2, Zero)) { Return (Buffer (One) { 0x03 }) } Return (Package (0x0C) { "AAPL,slot-name", Buffer (0x08) { "AirPort" }, "built-in", Buffer (One) { 0x00 }, "device_type", Buffer (0x08) { "AirPort" }, "name", Buffer (0x10) { "AirPort Extreme" }, "model", Buffer (0x3A) { "AzureWave AW-NB290H 802.11 b/g/n Wireless Network Adapter" }, "compatible", Buffer (0x0D) { "pci14e4,43a0" } }) } [...] } Try the following revised DSDT and report accordingly. DSDT.aml.zip

What version of OS X do you run? Please post your DSDT and IO80211Family kext (should be in /S/L/E unless you have a patched copy somewhere like in /L/E or /E/E with a Chameleon/Enoch-based installation or CLOVER/kexts/10.x with a Clover-based installation). Help us help you here...

BCM943225HMB, yes same thing. You have AzureWave AW-NB290H model, so indeed Ven/Dev id = 14e4:4357. What actions did you take to get it working (not normally working OOB afaik)? Brcm4360 kext patching or DSDT injection? I've read several reports of people complaining about performance with this card. It'll surely depend on the type of wireless network you attach to: 2.4GHz (lower speed) or 5GHz (higher speed) network, i.e. your wireless box/router capability.

In IOReg output or lspci command output (if lspci package installed) or DCPIManager app; that kind of stuff. Do you have the make and model at hand? If confirmed to be 14e4:4357 as expected, you normally need to patch the Brcm4360 kext or your DSDT to inject your card details.

What are the PCI ids? 14e4:4357?

? What relation would there be between patching AppleHDA and a CPU stuck at 1.6GHz? For maximised CPU power management performance, make sure to: 1) enable all cores and SpeedStep in BIOS 2) for C2D and 1st gen Arrandale Core CPU, enable/activate C States & P States generation 3) A fine-tuned FakeSMC (SMC keys) often help for vanilla SpeedStepping + AGPM too To inject a specific audio layout-id, patch your DSDT according to the following examples: Device (HDEF) { Name (_ADR, 0x001B0000) [...] Method (_DSM, 4, NotSerialized) { [...] Return (Package (0x--) { [...] "layout-id", Buffer (0x04) { 0x0C, 0x00, 0x00, 0x00 }, [...] }) } } or Device (HDEF) { Name (_ADR, 0x001B0000) [...] Method (_DSM, 4, NotSerialized) { [...] Store(Package (0x--) { [...] "layout-id", Buffer (0x04) { 0x0C, 0x00, 0x00, 0x00 }, [...] }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } ` There are many examples scrounging this forum and the Net, you'll easily find some. Here, for instance.

Problems with sleep, LAN & GPU throttling all sorted after tuning of FakeSMC + AGPM. FakeSMC kext replaced by a refined version that includes the SMC keys + AGPM tuning as detailed here and here. A copy of the kext is available in the D630 EC 10.11 pack posted here. Wifi cards are unsupported Intel 3945ABG and Atheros AR5BXB6, so both have to be replaced.

AirPortBrcm4360 patch detailed here.