Hervé

Yes, it may just be that your particular Intel model is somehow "slow" to respond to BIOS or adapter sensing and thereby somehow not 100% compatible or suitable. If you read the previous posts in this thread, you will see several positive reports with various non-Intel mSATA SSDs, whilst there is a previous negative report about an 80Go Intel 310 Series model. To me, no need to look further, it's probably the SSD itself. mSATA SSD tested/reported OK: Plextor PX-128M5M 128Go Crucial M4 256Go MyDigital BP4 240Go Lite-On LMT-256L9M 256Go Samsung SM841N 256Go mSATA SSD tested/reported NOk: Intel 310 Series 80Go Other mSATA SSD candidates: Kingston SMS200S3 120Go ... I must admit I've experienced disappointments with other Intel SSD too: I have a "regular" 2.5" Intel 330 series in my D630 and it slows down dramatically if I enable TRIM on it. I've never experienced such things with SSD from a different make.

True, but during performance tests we ran a couple of years ago, we did notice that MBP5,1 profile face a better performance and GPU throttling than the MB5,1. Regarding DSDT, the file you posted refers to Device (AGP) and you said you renamed it to GFX0. Isn't the case any more? Anyway, you know what to do now, the AGPM tuning thread should be sufficiently explanatory.

By the way, you probably would not get anywhere with DSDT editing and renaming APG device to GFX0 on a MacBook5,1 SMBIOS profile; If you check your AGPM Info plist, you should see that the entry associated with that model only caters for the integrated chip (IGPU). You really should opt for a MacBookPro5,1 SMBIOS profile, tune the system as per the dedicated thread and article, then proceed with AGPM tuning.

So, you've changed mSATA to ZIF adapter and problem remains? We can rule out a faulty adapter then, which leaves you with following likely causes: damaged ribbon cable loose/unreliable ribbon cable connection (ZIF end and/or adapter end) wrong SSD partition scheme or format type faulty or somehow incompatible SSD

what bootloader and Azul FB/ig-platform-id value are you using?

I would suggest you simply concentrate on patching the AGPM kext since that'll be required, with or without AGP device renaming to GFX0 in the DSDT. But it's entirely up to you in the end.

You asked what ig-platform-id value you should use. It depends on the computer and its integrated Intel HD 4x00 graphics. That's why I suggested you try the values in the range detailed by RampageDev as you may actually find you obtain graphics acceleration with a different value than expected. Now, if you already know which values work, why ask? Just try and if it does not give you satisfaction, try the other values until you find the value that does.

Look at this thread; it should answer your questions and point you in the right direction.

You may try ig-platform-id values that belong to the range detailed in RampageDev's Intel HD4400 guide.

Any Merom or Penryn Core2Duo CPU with FSB800 will do. Do not install a Penryn model with FSB1066 as, if it ran at all, it would only do it at FSB800 and therefore at much reduced speed than you'd expect. So Penryn T9300 and T9500 CPUs are Ok but don't opt for the T9600. The Penryn Extreme X9000 should work too, but you'd probably experience quite high T°...

"No such file or directory" is usually self-explanatory... Did you actually verify presence of IOBluetoothHostControllerUSBTransport plug-in or perl target binary file in the IOBluetoothFamily kext on your system? It certainly is there for me in 10.10.5 so it would seem you somehow deleted it.

For those X201/X201s owners who have an erroneous Intel HD Graphics GPU reported in SysProfiler with dev id 0x2d10, try adding statement Name (_UID, 0xFF) to Device (UNCR) of your DSDT: Device (UNCR) { Name (_BBN, 0xFF) Name (_UID, 0xFF) // fix issue of QPI link 0 (pci8086:2d10) being reported as GPU in SysProfiler Name (_ADR, Zero) Name (RID, Zero) Name (_HID, EisaId ("PNP0A03")) Name (_CRS, ResourceTemplate () { WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode, 0x0000, // Granularity 0x00FF, // Range Minimum 0x00FF, // Range Maximum 0x0000, // Translation Offset 0x0001, // Length ,, ) }) Device (SAD) { Name (_ADR, One) Name (RID, Zero) OperationRegion (SADC, PCI_Config, Zero, 0x0100) Field (SADC, DWordAcc, NoLock, Preserve) { Offset (0x40), PAM0, 8, PAM1, 8, PAM2, 8, PAM3, 8, PAM4, 8, PAM5, 8, PAM6, 8 } } } To reflect true MBP6,1/6,2 DSDT implementation, the brave ones may also consider: renaming Device (SAD) + subsequent references to SAD by IMCH renaming Device (UNCR) + subsequent references to UNCR by CPBG

Updated ok to DB8, though renewed trouble with cache...

The patched AICPUPM prevents KP on CPU power management. For the rest, it is self-explanatory.

Are you using distros?

Ouh... where to start? You could start looking at out EDP->Documentation pages. There are also excellent AIO guides at InsanelyMac that I can recommend. However Hackintoshing is a never-ending redo-it-all-again kind of adventure so you learn something new everyday... One thing strikes me in your above picture: I see OS X version 14F27 (i.e. Yosemite 10.10.5), yet Darwin version is 14.0.0, i.e. kernel of Yosemite 10.10(.0). That's rather odd...

With ML, you'd probably need to rollback AppleACPIPlatform kext to SL 10.6.7/10.6.8's version v1.3.5/v1.3.6 to avoid KP. I would suggest you start with Mavericks on a myHack build from which you can learn and then consider upgrading to Yosemite and El Capitan (in due course).

Please list the target OS X version you're trying to install and the bootloader you're using. Ideally, boot without cache and in verbose mode so that you can tell us the point at which the system appears to hang.

sudo touch -f /System/Library/Extensions sudo kextcache -Boot -U / -> You'll see the list of unsigned kext as reported by the OS. Basically, most add-on kexts and all modified/patched (ex-vanilla) kexts will be reported as "unsigned".

One can't really use the installer app as is (unless from an existing Clover-based OS X installation) but build a USB installer from it.

I doubled checked and all would appear to be Ok, except maybe the cosmetic aspect of the Bus speed. Arrandale i5-520M has a nominal frequency of 2.4GHz at x18 multiplier and lowest frequency of 1.2GHz at x9 multiplier. It has a Turbo boost at x20, i.e. 2.66GHz for 2 cores and x22, i.e. 2.93GHz for 1 core. That makes for a bus speed of 2.4/18 = 1.2/9 = 2.66/20 = 2.93/22 = 133MHz. OS X reporting a bus speed of 533MHZ, it appears the OS is considering CPU bus speed like a good old quad-pumped FSB even though it's not really applicable to an Arrandale CPU. http://ark.intel.com/products/47341/Intel-Core-i5-520M-Processor-3M-Cache-2_40-GHz http://www.cpu-world.com/CPUs/Core_i5/Intel-Core%20i5%20Mobile%20I5-520M%20CP80617004119AE%20(BX80617I5520M).html

I was using v1.3 from the SourceForge repo but I've now updated to v1.3(252) and I can compile the DSDT Ok.

The SD card reader is attached to Device (PXSX) @ _ADR = Zero under Device (RP01) @ _ADR = 0x001C0000, itself directly under Device (PCI0). Look it up in your DSDT. On the basis that it is PCI device 1217/8520, i.e. the well-known 02 Micro SD card reader, it should work OOB once you add the usual compatibility statement to the afore mentioned Device (PXSX) in your DSDT: Device (PXSX) { Name (_ADR, Zero) Method (_DSM, 4, NotSerialized) { Store (Package (0x08) { "AAPL,slot-name", "Built-in", "device_type", Buffer (0x11) { "Media controller" }, "model", Buffer (0x18) { "O2 Micro SD card reader" }, "compatible", Buffer (0x0D) { "pci14e4,16bc" } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } ... You can read more details about this here. I've tried to patch the DSDT posted by Jake, but trying to compile it with DSDTEditor or MaciASL in ACPI v4.0 or v5.0 gives me 25 errors even before applying the patch...

I would not want to speak out for people who experimented or use the E6410 Intel HD with partial acceleration but, having tried it myself, I can tell you that any system running without graphics acceleration is just painful. To me, there is really no point in running OS X in limping mode where anything a little graphical like moving or minimising a window is effectively laggy.

Well, one might say that Mavericks would mean you could use myHack and that it would therefore be easier, but I don't think it'll change anything if you have the wrong settings or wrong bootpack. Remember that you will only ever get partial graphics acceleration on that system (Intel HD of the E6410 is not fully supported due to display connector; see here for details), so you may actually prefer not to install OS X on it as It'll never be a particularly great experience.