Hervé

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.

Try the attached. 10.11.3_ALC292-AppleHDA_pack.zip NB: The included FakePCIIDxxx kexts are only applicable if you have/use integrated Haswell Intel HD graphics and want HDMI audio.

What's interesting? You have an Ivy Bridge system with Intel HD4000 graphics. That's managed by the Capri Framebuffer and the Intel HD4000 kexts. As such, it's perfectly normal that none of those IntelHD (1st gen HD), SNB (2nd gen HD3000), Azul (4th gen HD4x00/5000) or BDW (5th gen Broadwell) framebuffers load. You won't fail to notice that the Capri Framebuffer and HD4000Graphics kexts are however loaded, as expected. Regarding USB kexts: "UHCI" is the controller for USB1.x ports "OHCI" is a standard controller for USB1.1 ports (usually non-Intel hardware) "EHCI" is the controller for USB2.0 ports "XHCI" is the controller for USB3.0 ports https://en.wikipedia.org/wiki/Host_controller_interface_(USB,_Firewire) If your laptop does not possess the hardware, the associated kexts do not load; that's perfectly normal. For USB3.0 ports, Hackintoshes often require add-on/generic/3rd party kexts to support thems. I'm sure you'll find that the AppleUSBEHCIxxx kexts are loaded for USB2.0 ports though. Different kexts have different loading conditions and different effect. Look at the Info plist of the AppleUSBECHIPCI kext and you'll find references to IOClassMatch and a list of Mac models with details of port numbering. That port numbering was something new which caused all the trouble when EC 1st came out. Apple did tie up the way they handle USB2.0 ports. If you do the same exercise with AppleUSBXHCIPCI, you'll see that there are references to IOClassMatch or IOPCIPrimaryMatch. The latter is a specific reference to hardware PCI id and only triggers the loading of the associated kext if the underlying hardware does match. Afaik, what you see is perfectly normal. For your education, you'll find interesting and valuable information here.

What wifi card do you have? Incorrect reported CPU speed could be due to the bus speed configured in your Clover config file. With a Penryn C2D, it should be set to 200000khz (200MHz, i.e. the base speed of the quad-pump FSB). GPU sticking at 400MHz is clearly a lack of tuned AGPM. You can lookup the dedicated thread on the matter in the R&D ->Other research section. I've also posted details of the manner in which you can incorporate this particular tuning into FakeSMC, thereby removing the need to patch AGPM kext after each update or installation. I'll have to check LAN status after wake since I hardly ever use it. I certianly don't recall experiencing loss of LAN after wake, yet I have virtualization enabled in BIOS; but I'll check this out on my D630 under EC.

It sounds like you may not be using an adequate version of Chameleon. For Yosemite, I can vouch for older versions such as r2395, 2401 or 2468 for instance. However, you may want to switch to the Enoch branch that has the attention of developers these days. Version r2795 works perfectly for me. Enoch includes some on-the-fly kernel patches and/or kext loading mechanism which are very interesting.

You can confirm what kext applies or should apply to your card by looking at the PCI ids listed in the Info plist of each kext. DW1520 normally bears Vendor id 14e4 (i.e. Broadcom) and device id 4353. You'll clearly see that inside AirPortBrcm4360 (and Brcm4331 too!) but not in the Brcm43224 kext. That one is for older 802.11a/b/g cards such as the DW1390, DW1490, etc.

FaceTime will most definitely work as long as you have a supported webcam. iMessages... well it's quite complicated these days, so absolutely no guarantee I'm afraid.

That's apparently based on Qualcomm Gobi3000 (MDM6600) chipset. Look up the existing threads related to that chip. Sierra MC8355 or MC8305 are based on that chipset.