Hervé

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.

There are no kext (or kext-related info) to extract or inject in a SMBIOS file per sé, but maybe it was an excess of language on your part. In the context of Hackintoshing, a SMBIOS plist file is "just" a text file used to pretend your computer is the targeted Mac model. The limitation experienced with this particular wifi card model is within the vanilla wireless kext, not within the MBA5,2 SMBIOS file in which there's nothing you can extract to inject in the MBP6,2. As indicated by Jake, it's the Broadcom kext that needs patching to support non-MBA5,2 profiles. Forgive the analogy but consider it like trying to get an elephant through a cat door. Not much you can take from the cat for the elephant, it's the door that needs a bigger hole!

You have landed on this Hackintosh forum so I take it you're aware of what a Hackintosh is, aren't you? Can you confirm your Precision model as the high-end Tower 7910 workstation (no 9710 as far as I can see)? Post your detailed hardware specs (chipset, LAN, Audio, graphics card) so that we get a better idea re: potential as a Hackintosh.

I would not expect everything to run on a VM, especially tricky apps such as iMessages that rely on real hardware elements (serial numbers, Ethernet interface, etc) and for which Apple introduced locking mechanisms some time ago. Why not opt for a proper Hackintosh installation instead?

Following up on my experiments with the PCIe x1 Marvell 88SE9123 controller, I tested the Syba SD-PEX50055 card (which has also been mentioned on other forums). It offers 2 x SATA-III ports + 2 x USB3.0 ports on a PCIe 2.0 x4 card. The card is based on the ASMedia ASM1062 SATA-III controller and the Etron EJ168A USB3.0 controller. The SATA-III controller works OOB in Snow Leopard, Lion, Mountain Lion, Mavericks and Yosemite. It just requires power (using a floppy-type connector). By default, it's listed as "Unknown AHCI controller" under SL and as "Generic AHCI controller" in more recent OS X versions such as Mavericks or Yosemite, which can easily be fixed through a little patch of AppleAHCIPort kext. Just insert the card in a supporting PCIe slot (x4, x8 or x16) and attach the disk(s). Perfect for older desktop PCs that do not have a SATA-II/SATA-III/AHCI capable controller and wish to enjoy SATA HDDs or SSDs at PCIe speed and, for SSDs, enable Trim. USB ports only operate as USB2 speed when the card is fitted in a PCIe v1.0 slot. In addition, they are not supported in SL 10.6, only from Lion 10.7. http://www.sybausa.com/index.php?route=product/product&path=64_77_85&product_id=177 WS670:~ admin$ lspci -nn pcilib: 0000:08:00.0 64-bit device address ignored. [...] 04:00.0 PCI bridge [0604]: Pericom Semiconductor Unknown device [12d8:2304] (rev 05) 05:01.0 PCI bridge [0604]: Pericom Semiconductor Unknown device [12d8:2304] (rev 05) 05:02.0 PCI bridge [0604]: Pericom Semiconductor Unknown device [12d8:2304] (rev 05) 06:00.0 SATA controller [0106]: ASMedia Technology Inc. ASM1062 Serial ATA Controller [1b21:0612] (rev 01) 07:00.0 USB controller [0c03]: Etron Technology, Inc. EJ168 USB 3.0 Host Controller [1b6f:7023] (rev 01) [...] WS670:~ admin$ ` Although coming on a x4 format, the card is actually PCIe x2 (i.e. limited to 2 x PCIe lanes). Still, I was holding high hopes of being able to gain improved performance at full or near-full SATA-III (600MB/s) speed off my SSD in my ancient PCIe 1.0 workstation. Unfortunately it proved not to be the case. The card only seems to operate at 1 x PCIe lane per SATA port in my PCIe v1.0 x8 slot (operating at x4). BlackMagic speed test gave somehow disappointing results with a read speed of 200MB/s and a write speed of 166MB/s, i.e. it's a little slower reading than the Marvell controller but a little quicker writing.

https://osxlatitude.com/index.php?/topic/2513-i-must-be-dumber-than-a-mule/?hl=%2Bmodcd+%2Bd630&do=findComment&comment=18890 https://osxlatitude.com/index.php?/topic/2897-someone-please-direct-me-to-an-appropriate-guide/?hl=%2Bmodcd+%2Bd630&do=findComment&comment=22207 Old stuff of course, but generally 95% still applicable. I highly recommend that you skip the EDP part and use the full packs I provided instead. But it's up to you of course...

HDMI audio if you have HDMI.

Try the attached 10.11.3 AppleHDA kext (v272.51.3) patched for IDT 92HD71 (you'll have to remove VoodooHDA + AppleHDADisabler kexts). You may need to add EAPDFix + CodecCommander in order to gain jack/headphone output and audio after sleep (but check without 1st). If audio works with patched AppleHDA, try re-instating SpeedStep in BIOS too. AppleHDA_IDT692HD71.kext.zip EAPDFix.kext.zip CodecCommander.kext.zip