Hervé

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.

I knew this would be your next question, so I anticipated a little! https://osxlatitude.com/index.php?/topic/8739-patching-airportbrcm4360-kext-for-unsupported-mac-models/

We've had many posts from users who have a wireless card controlled (and sometimes natively supported) by the AirPortBrcm4360 kext in their laptop Hackintosh but are not able to get it to work unless they opt for, say, the MacBookAir5,2 SMBIOS. The DW1520 wifi card is one of those for instance: 14e4:4353 is supported OOB but only with some SMBIOS such as MBA5,2. It's also been stated that reason for this was "whitelisting" by Apple in the kext, i.e. Apple have specified a set of Mac models for which the card would work (and would not work for others as a consequence). Those who want to get their cards working without switching to MBA5,2 SMBIOS have little choice but patching the kext in order to "inject" their specific profile. In this case, we're not talking about a simple traditional PCI id injection in the kext's Info plist, we're talking about binary patching the kext's binary file. NB: some cards are not natively supported by the kext and PCI device patching (injection) is then required in the Info.plist file, i.e. "double" patching so to speak... Let's look at the kext binary file to start with (it's located in the Contents/MacOS folder inside the kext package). Here, we'll look at the file from El Capitan 10.11.3 but the principle remains the same for other OS X versions/releases. The file contains a list of supported Mac models (aka a whitelist), a list expressed with references to product board in the form "Mac-<Hexadecimal string>". In the above picture, we can clearly see the reference to MacBookAir5,2 board id "Mac-2E6FAB96566FE58C", something we can confirm with Chameleon Wizard or Clover Configurator SMBIOS tab if required: In order to modify the kext to support an unsupported model, we're going to binary patch it by replacing an existing board reference by that of the targeted/desired Mac model. For instance, if we want to add support for the MacBookPro6,2 Mac model, we're going to replace all the octets referring to the MacBookAir5,2 board id (but we could replace another model of course) by those referencing the MacBookPro6,2's. There are various ways to binary patch the kext: use a hex editor such as 0xED or Hex Fiend for instance, use a perl command from Terminal, or even use the Clover on-the-fly mechanism. Whilst a hex editor will support text (ASCII) replacement as well as hexadecimal replacement, perl will require sole use of hexadecimal octets. It is therefore necessary to convert the text string to hexadecimal in that case. Whilst the computer-literate people would be able to do this manually, non-IT people would find this rather tedious; fortunately there are various conversion tools around these days, including online (e.g.: http://hex.online-toolz.com/tools/text-hex-convertor.php). Generally speaking, it's always recommended to proceed with the hexadecimal replacement to avoid any confusion in text/ASCII. In the case of the MacBookPro6,2 (board product: Mac-F22589C8), we obtain the following hex string: 4D 61 63 2D 46 32 32 35 38 39 43 38 (i.e. the hexadecimal notation of each ASCII character) We can also notice that this particular board product contains 8 digits, i.e. less than the 16 digits of the models listed in the kext. With regards to binary patching, we'll therefore replace the "missing" 8 digits by null octets set to 00, making the replacement string: 4D61632D46323235383943380000000000000000 ` The binary patch can therefore be applied in the following manner: For those using Clover, on-the-fly patching is done through the usual Find/Replace method. For instance: Kext: AirPortBrcm4360 Find: 4D61632D32453646414239363536364645353843 --> MacBookAir5,2 Replace: 4D61632D46323235383943380000000000000000 --> MacBookPro6,2 Here's an example previously posted by JakeLo for injection of MacBookPro8,2 reference (text in Clover's config.plist): <dict> <key>Comment</key> <string>DW1520 Whitelist Patch (MBP8,2)</string> <key>Find</key> <data> TWFjLTJFNkZBQjk2NTY2RkU1OEM= </data> <key>Name</key> <string>AirPortBrcm4360</string> <key>Replace</key> <data> TWFjLTk0MjQ1QTM5NDBDOTFDODA= </data> </dict> Like many other plist files, Clover's config.plist makes use of Base64 code for data. As such, test must be converted to Base64 code before it's entered through a text editor. Again, there are online tools to help with this (e.g.: http://online-toolz.com/tools/text-base64-convertor.php). The Clover Configurator app will provide a much easier mechanism to program this patch as plain text can be used instead, the app doing the conversion for you. In a nutshell, in order to binary patch the AirPortBrcm4360 for an unsupported Mac model, one needs to: identify the board product id of the targeted/desired model convert that board id from text to hex add any necessary trailing null (00) octets to obtain the required 20bytes string binary modify/patch the kext to replace the 20bytes string of an existing model the 20bytes string of the desired model NB: As usual, always keep a backup of the vanilla kext somewhere. To patch the kext, make a copy of the vanilla kext outside /S/L/E (like on the desktop) and patch that copy. The patched kext can then be copied/moved to /S/L/E, permissions repaired and cache/prelinked kernel rebuilt. Direct patching of a kext located in /S/L/E (or /L/E) is usually not allowed due to permission restrictions.

Sounds like you need a DSDT patch for USB devices (EHCx)... Post your DSDT.