Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

OS X El Capitan Opens Door to TRIM Support on Third-Party SSDs for Improved Performance

Great find @Temptin !!

Wish I could say this hack worked on this end though..

I followed the exact same steps listed under the second method, which doesn't require kext-dev-mode to be on, and couldn't get TRIM to be enabled on my Mac Pro. I disabled/deactivated TrimEnabler prior to carrying out your method.

2015-06-20_12-22-21.png

2015-06-20_12-51-40.png

2015-06-20_12-51-13.png

2015-06-20_12-25-47.png

The AppleDataSetManagement.kext isn't being loaded due to:

Dependencies: Incomplete
Dependency Errors:
Dependency Resolution Failures:
Kexts already loaded for these libraries have no OSBundleCompatibleVersion: com.apple.iokit.IOAHCIBlockStorage
Signed by: Software Signing, Apple Code Signing Certification Authority, Apple Root CA

What did I miss?

Any help would be appreciated.

Thanks!
 
W1SS said:
Great find @Temptin !!

Wish I could say this hack worked on this end though.. [...] The AppleDataSetManagement.kext isn't being loaded due to:

Dependencies: Incomplete
Dependency Errors:
Dependency Resolution Failures:
Kexts already loaded for these libraries have no OSBundleCompatibleVersion: com.apple.iokit.IOAHCIBlockStorage
Signed by: Software Signing, Apple Code Signing Certification Authority, Apple Root CA

What did I miss?
Click to expand...

Not sure why the extension doesn't load. But I do have a 10.10.4 test drive also and used the first, manual method on it, just to test all options Temptin has described. It worked for me there. You could give it a shot
10.10.4 & Trim Support = Yes.png
 
zzzachi said:
what a joke!
there was never a need to validate devices for the use of trim.
why should a drive accept the ata trim command if it wasn't able to handle it securely..
Click to expand...

... you'd think, however Linus Torvalds (linux fame) has run into plenty of hardware which lies about support of features. As have the ZFS developers. SSDs and hard drives included.

So, interrogating the drive and asking "Do you support trim?" by the OS is BY NO MEANS a guarantee that it will work, and it can cause data corruption. Hence Apple's warning when running trim force. Apple do QA on their supplied SSDs (or possibly even patch OS X to ensure they don't run into any edge case problems with those particular drives) to ensure they behave properly.

So in summary: its not a joke, it is merely apple being very conservative with enabling features on third party hardware they do not provide, and getting blamed for the data corruption that may occur.

Apple's reputation is "it just works" and enabling third party hardware to potentially ruin that experience (data loss) for some small performance gain (again, on hardware they never supplied) would just be silly of them.


Yes, most modern drives probably do work with trim. But the risk (for apple, enabling it on non-certified devices and getting blamed for the data loss) is there.

And there are still risks with TRIM:
http://linux.slashdot.org/story/15/...linux-tread-cautiously-and-keep-backups-handy

Stolen from a /. comment on the issue - comments from the source code regarding drives known to have issues with trim under some conditions:

/* devices that don't properly handle queued TRIM commands */
Micron_M500*
Crucial_CT*M500*
Micron_M5[15]0*
Crucial_CT*M550*
Crucial_CT*MX100*
Samsung SSD 8*
 
Last edited:
  • Like
Reactions: satcomer and DCIFRTHS
Fangio said:
Not sure why the extension doesn't load. But I do have a 10.10.4 test drive also and used the first, manual method on it, just to test all options Temptin has described. It worked for me there. You could give it a shot
View attachment 562701
Click to expand...

I have no doubt the first method will work as it involves modifying a plist file which in turn creates a dependency on having the 'kext-dev-mode' option enabled. I am trying to avoid this approach as I want peace of mind when installing OS updates which is why I'm focused on getting the alternative 'better' method to work.

Not sure if this matters but I'm running my SSDs off a Sonnet Tempo SSD Pro card... Could it be an Intel chipset restriction?
 
Last edited:
W1SS said:
I have no doubt the first method will work as it involves modifying a plist file which in turn creates a dependency on having the 'kext-dev-mode' option enabled. I am trying to avoid this approach as I want peace of mind when installing OS updates which is why I'm focused on getting the alternative 'better' method to work.

Not sure if this matters but I'm running my SSDs off a Sonnet Tempo SSD Pro card... Could it be an Intel chipset restriction?
Click to expand...

the System Profiler lists the KEXT as "Loaded: No" indeed. but it works flawless for me otherwise. have it running on several machines, TRIM ist activated.
 
mikeboss said:
the System Profiler lists the KEXT as "Loaded: No" indeed. but it works flawless for me otherwise. have it running on several machines, TRIM ist activated.
Click to expand...

Are you getting any dependency errors under AppleDataSetManagement? ie. "Kexts already loaded for these libraries have no OSBundleCompatibleVersion: com.apple.iokit.IOAHCIBlockStorage"
 
W1SS said:
Are you getting any dependency errors under AppleDataSetManagement? ie. "Kexts already loaded for these libraries have no OSBundleCompatibleVersion: com.apple.iokit.IOAHCIBlockStorage"
Click to expand...

yup, I'm getting exactly the same output as shown on your screenshot.
 
Thanks @mikeboss and @Fangio

Just as I suspected... The AppleDataSetManagement TRIM hack appears to only work with SSDs mounted on Intel/Generic AHCI Controller devices with an IOProbeScore of 800 reserved for Generic and 2000 for Intel/Nvidia.

I've checked Apple's list of controller devices and Marvell wasn't included which led me to believe that the cosmetic hack (custom kext) that I had previously devised to change the external storage drive icons (orange) to the internal icons (grey) was at fault.

I finally managed to get @Temptin TRIM hack, using El Cappy's ADSM kext, to work with my controller's custom kext by appending a customized com_apple_iokit_data_set_management key and modifying the IOProbeScore to 2000.. the result:

2015-06-20_20-50-56.png

;)
 
W1SS said:
I have no doubt the first method will work as it involves modifying a plist file which in turn creates a dependency on having the 'kext-dev-mode' option enabled. I am trying to avoid this approach as I want peace of mind when installing OS updates which is why I'm focused on getting the alternative 'better' method to work.
Click to expand...

Thought so already ;) and I agree, Temptins even better method by installing the ADSM.kext from El Cap is definitely the preferable way. Not to forget also, it is easily reversible. The first method based on an injection to the IOAHCIBlockStorage.kext's Info.plist is not so easy to turn off for average users. It would require either some advanced knowledge of creating terminal commands, or an undo command included..

Impressed by your troubleshooting skills btw, congrats.
 
Last edited:
  • Like
Reactions: w1z
@W1SS @Fangio @mikeboss

The AppleDataSetManagement extension is not supposed to fully load (since it contains no executable binary), so the error message you're both seeing is the way it should be. This is what my system info looks like; and as you can see it's not loaded here either:

notloaded.png
The kernel sees the ADSM extension and reads its Info.plist, which in turn causes the "Force Data Set Management" option to be injected into IOAHCIBlockStorage.kext. That's the option that tells their SATA driver to send TRIM to 3rd party drives.

As for what controller I'm using, it's a HighPoint Rocket 640L (PCI Express x2 card) which uses the Marvell 88SE9230 chip. The driver for that card is built into OS X so there was no need to install any 3rd party driver.

Under the SATA/SATA Express tab the card is identified as a Generic AHCI Controller:

genericahci.png

Under the PCI tab, you can see the exact vendor details for it:

pci1b4b,9230:

Type: AHCI Controller
Driver Installed: Yes
MSI: Yes
Bus: PCI
Slot: Slot-3
Vendor ID: 0x1b4b
Device ID: 0x9230
Subsystem Vendor ID: 0x1b4b
Subsystem ID: 0x9230
Revision ID: 0x0010
Link Width: x2
Link Speed: 5.0 GT/s

Now I am curious, @W1SS, you say you have a Marvell card that didn't work, and you mention that you had to install a 3rd party driver for it? I suppose that means your AHCI card isn't bootable either. I would suggest swapping it for one with built in OS X drivers.

What Marvell chip/card do you have? I may want to note this problem in the instructions.

And you say that you set a custom "com_apple_iokit_data_set_management" key on your 3rd party kext and modified its IOProbeScore. But how did you get the kernel to load that modified kext? Are you still running kext-dev-mode then, or did you actually sign your custom kext?

A bunch of questions, hehe, but I'm curious. If it turns out you're actually stuck with kext-dev-mode for your custom SATA card driver, then I *really* suggest buying the Rocket 640L instead (it's EFI-bootable too), or a similar card with natively supported chipset.
 
Last edited:
  • Like
Reactions: Weaselboy
@Fangio: Since you and others have expressed a desire for removal commands to disable TRIM again (what a crazy idea!), I've included them now for both the injection method and the official kext method. Github page updated. ;)

The link is available in Post #232 as usual. And please consider giving that post a thumbs up to make it even more visible.

@W1SS: I'll be updating the page with a notice about 3rd party SATA controllers when I know more from you about the issue and how you solved it. It's a bit strange that they seem to have limited trimforce to "if controller == apple OR generic ahci controller", but maybe they don't trust all controllers to pass TRIM through to the SSD reliably. Very odd... If this is true, then *anyone* who has a controller that requires 3rd party drivers will lose TRIM in El Capitan, since trimforce will be the only method of enabling TRIM on that OS. In that case, the only thing you can do is petition the vendors to update their 3rd party SATA controller kexts with the values you injected to get them detected by trimforce.

Edit: There's no problem! Trimforce works with any SATA card that works on OS X. The problem W1SS experienced was because he had created a custom kext "driver" for his card to change some icons, and his custom kext prevented his card from being identified as a compliant SATA controller.
 
Last edited:
  • Like
Reactions: Fangio and Weaselboy
Temptin said:
@W1SS @Fangio @mikeboss

Now I am curious, @W1SS, you say you have a Marvell card that didn't work, and you mention that you had to install a 3rd party driver for it? I suppose that means your AHCI card isn't bootable either. I would suggest swapping it for one with built in OS X drivers.

What Marvell chip/card do you have? I may want to note this problem in the instructions.

And you say that you set a custom "com_apple_iokit_data_set_management" key on your 3rd party kext and modified its IOProbeScore. But how did you get the kernel to load that modified kext? Are you still running kext-dev-mode then, or did you actually sign your custom kext?

A bunch of questions, hehe, but I'm curious. If it turns out you're actually stuck with kext-dev-mode for your custom SATA card driver, then I *really* suggest buying the Rocket 640L instead (it's EFI-bootable too), or a similar card with natively supported chipset.
Click to expand...

I have the Sonnet Tempo Pro SSD card with a Marvell 0x1b4b/0x9182 controller which works/boots flawlessly.

All AHCI compliant non-intel/nvidia based controllers are recognized by OSX as "Generic AHCI Controllers" due to the fact that Apple mainly uses a mix of intel/nvidia controllers in their hardware. While a compliant generic AHCI controller will be recognized/work in OSX with trim support, hard drives connected to generic controllers are identified as external drives and are thus assigned with the orange external drive icon. This can confuse users and often results in mistakenly ejecting the wrong drive which is why I created a custom kext specifically for Sonnet Temp Pro cards that correctly probes and identifies the card as a non-generic AHCI controller ie. Sonnet Temp Pro SSD so that any drive connected to the card would be recognized as an internal drive with a grey drive icon.

The issue here is that the ADSM kext together with the AppleAHCIPort kext only enables the 'new' TRIM on generic AHCI and intel/nvidia based controllers with a probe score of 800 or 2000 while the custom Sonnet kext I had devised had a probe score of 25000 and was not referencing the com_apple_iokit_data_set_management. Therefore, there was no way for OSX to correctly support trim with the custom kext I had created.

Enter the changes I made to the custom kext:

Added:

<key>com_apple_iokit_data_set_management</key>
<dict>
<key>CFBundleIdentifier</key>
<string>com.apple.iokit.IOAHCIBlockStorage</string>
<key>Force Data Set Management</key>
<true/>
<key>IOClass</key>
<string>AppleAHCIDiskDriver</string>
<key>IOProbeScore</key>
<integer>5000</integer>
<key>IOProviderClass</key>
<string>IOAHCIDevice</string>
<key>Protocol Characteristics</key>
<dict>
<key>Physical Interconnect</key>
<string>SATA</string>
<key>Physical Interconnect Location</key>
<string>Internal</string>
</dict>
</dict>

Modified the probe score from 25000 to 2000 which Apple uses for their intel/nvidia based controllers:

<key>SonnetTempoProSSD</key>
<dict>
<key>CFBundleIdentifier</key>
<string>com.apple.driver.AppleAHCIPort</string>
<key>Chipset Name</key>
<string>Tempo Pro SSD</string>
<key>IOClass</key>
<string>AppleAHCI</string>
<key>IOPCIClassMatch</key>
<string>0x01060100&amp;0xffffff00</string>
<key>IOPCIPrimaryMatch</key>
<string>0x91821b4b</string>
<key>IOProbeScore</key>
<integer>2000</integer>
<key>IOProviderClass</key>
<string>IOPCIDevice</string>
<key>Vendor Name</key>
<string>Sonnet</string>
</dict>

A probe score of 800 which apple uses for identifying compliant AHCI controllers as 'Generic AHCI Controllers' resulted in a kernel panic with the custom kext.

I was only able to load the custom kext with kext signing disabled which works for me as I do not have to worry about installing another OS update with a modified 'Apple' kext - the dreaded grey error screen. In other words, if kext signing becomes enabled again due to PRAM reset or an OS update, the custom kext I had created gets disabled and the card would be recognized as a 'Generic AHCI Controller' with ADSM trim support but with external orange drive icons assigned instead. More importantly, my mac pro would continue to boot without any issues... I'll take that over modifying/breaking the signatures of Apple kexts any day.

As for 3rd-party SATA controller vendors- The new ADSM trim method, aka trimforce, shouldn't impact them just as long as their controllers are manufactured according to AHCI specs and pass compliance testing.

That's pretty much it.. Let me know if you need additional information or would like a copy of the custom kext.
 
  • Like
Reactions: Temptin
@W1SS Thanks for the awesomely in-depth explanation! It's a relief to know that the issue was due to your custom kext and that trimforce will work with every 3rd party SATA card after all! For a moment I was worried vendors would have to start modifying all 3rd party drivers to be compliant.

The 0x1b4b vendor ID that we both have stands for Marvell. The device ID I have is 0x9230 which stands for 88SE9230. Your device ID is 0x9182 which stands for 88SE9182. Both of our Marvell chips (9230 and 9182) support EFI boot and driverless OS X operation, because their drivers are already built into OS X.

So to anyone reading: There is no problem with ADSM/Trimforce. This issue was because W1SS had created a custom kext which loads itself as a "driver" for the Tempo Sonnet card and changes it to be identified as an internal hard disk controller instead (to get rid of the "eject" buttons on all connected drives). He just had to update his kext a bit to get it to be supported.

---

By the way, W1SS, remember that El Capitan will not allow your custom unsigned kext, so if you're planning on upgrading, I suggest that you start running your machine without kext-dev-mode and without your custom kext and see if you get used to seeing the eject buttons. The orange disk icons and the eject buttons are just the nice hot-swap feature of SATA cards, letting you eject a drive and replace it without restarting the machine. The boot volume will never be ejectable no matter what (it won't have an eject button), so there's no risk of ejecting the system drive. You can only eject any extra drives you might have, and it will NOT eject drives that are in use (open files, etc). So the existence of eject buttons really doesn't matter, since they can't do any damage. And... if you accidentally unmount an "external" drive that you wanted to keep (has never happened to me), you can just go into Disk Utility and select it there and press the "Mount" button again, without a reboot.

One more thing: I don't think you need Force Data Set Management in your custom kext. And it looks like you've put it in an incorrect location anyway. If you look at ADSM.kext, it's supposed to go under IOKitPersonalities->
com_apple_iokit_data_set_management->Force Data Set Management. It seems you don't have the IOKitPersonalities heading, so I doubt that your "Added:" changes have had any effect. And since you're using ADSM.kext, I don't think you need to use it in your own kext anyway. Try it without those lines. Seems all your really needed to do was to change the IOProbeScore to 2000 to get the custom driver detected as an AHCI SATA controller. But even the "Probe Score" fix is weird, since the number only determines which driver is loaded (if two drivers match the exact same device ID, the one with the highest probe score is selected). It shouldn't affect what type of device it's detected as, unless Apple has decided to use "magic probe score numbers" in this case to differentiate AHCI devices. So it's possible some other change above fixed your kext. Well, it hardly matters since nobody on Capitan will be running custom kexts anyway...
 
Last edited:
  • Like
Reactions: w1z
@Temptin Glad I was able to make sense of this all...

As for the custom kext- see attachment, I actually do need "Force Data Set Management" in my kext as the Sonnet card/Marvell controller's device ids are not referenced in the AppleAHCIPort kext and without this setting, TRIM would remain disabled for this 'specific' kext hack. You will also notice that I have correctly referenced the IOKitPersonalities heading ;) I just didn't copy and paste the entire kext on here. The 2 IOKitPersonalities in the kext are required (I've tested this).

Thanks again for this great find.
 

Attachments

  • 2015-06-21_23-27-17.png
    2015-06-21_23-27-17.png
    301.5 KB · Views: 297
@W1SS Ahh, good, you put them under the correct heading.

Although you're mistaken about AppleAHCIPort. It doesn't contain your device ID, and not mine either. That's not how it works. The GENERIC class is specified as follows:

GenericAHCI:
- Chipset Name = AHCI Controller
- Vendor Name = Generic
- IOProbeScore = 800 (very low score, thus allowing specialized 3rd party drivers to be loaded instead if they have a higher priority; for example, their more specific intel/nvidia definitions have a score of 2000 instead so that they won't use this generic definition)
- IOPCIClassMatch = 0x01060100

Note that the generic header uses a PCI *CLASS* (basically "type of device") match, NOT an exact device ID match. So *any* "class compliant" PCI device which identifies itself as class/type 0x01060100 (the class for "SATA AHCI Controller"), will be matched by the "GenericAHCI" definition and will be handled by AppleAHCIPort.kext. That includes your card, and my card, since they're both using the proper PCI Device Class. They'll be named "Generic AHCI Controller".

So now let's see what your kext is doing... At the bottom, it injects an option into AppleAHCIPort. You are adding an entry with a IOPCIPrimaryMatch of 0x9182 (the exact marvell controller on your card), which names your card "Sonnet Tempo Pro SSD". That's what causes your card to have a new name in System Information, but it's totally pointless since it can only be seen there. I would get rid of that AppleAHCIPort section completely.

Next, the meat of what it does: At the top, it injects an option into IOAHCIBlockStorage, which tells it to treat *ALL* disks on *ALL* controllers (not just yours) as internal. To be exact, it overrides the IOKitPersonalities array of IOAHCIBlockStorage, with a new one which tells it to treat all drives as internal, and which also sets the force data set management flag to true. You could actually make both of those changes directly to IOAHCIBlockStorage, but as you already know you'll break the signature in that case.

But what this basically means is that you can remove the AppleAHCIPort section (it's not necessary, your kext will be loaded anyway). It also means that you can delete AppleDataSetManagement.kext since yours is doing the same injection (plus your "View all devices as internal drives" change).

If AppleDataSetManagement.kext ever loads *after* your kext (they're probably loaded in alphabetical order but it's not guaranteed), it will override IOKitPersonalities of IOAHCIBlockStorage and undo your "show all drives as internal" change.

As long as you're going to keep running with kext-dev-mode=1 anyway, you might as well get rid of AppleDataSetManagement.kext since you're doing the same injection work + your "show all drives as internal" change in your own kext.

This was also why your kext prevented AppleDataSetManagement.kext from working; you were doing the "show all drives as internal" override *after* AppleDataSetManagement.kext had been loaded, thus overwriting everything it had done, and replacing it with a new option array without any Force Data Set Management flag.

Just thought you might find this info interesting. It had nothing to do with IO probe priorities or anything else. Just a simple issue of two kexts trying to override the same options array. ;)
 
Last edited:
In El Capitan Developer Beta 2:

TRIM by default - turned off.
But those who activated the trim in beta 1 - continue to use it ...

Also, Apple has made it possible to run trimforce in protected system.
sudo trimforce enable and sudo trimforce disable in beta 2 - no need rootless=0
 
@casperes1996: It's simple. If multiple kexts match the device manufacturer / chip id / chip class (like "AHCI Controller"), the one with the highest IOProbeScore is picked. It is only a priority number and numbers mean nothing, but it seems Apple has developed some standards so that it's not all crazy. They use 800 for low-priority generic drivers and 2000 for specific drivers, at least in the disk storage driver.

@Skvo: I don't have (or want) Developer Preview 2 so I can't verify that, but according to "richardshears" (click and search for his name there) using DP2 the utility still tries to write to /System which is blocked by rootless. You're probably experiencing a rootless bug which allows you to write even though it should be blocked for you too. Same issue happened in DP1: Some people could write to /System even when rootless said "enabled."

This is my last post at MacRumors. Everything to be said has been discussed now. Great work everyone! We won. We have official TRIM and it'll only get better with time. :)
 
Last edited:
Temptin said:
@casperes1996: It's simple. If multiple kexts match the device manufacturer / chip id / chip class (like "AHCI Controller"), the one with the highest IOProbeScore is picked. It is only a priority number and numbers mean nothing, but it seems Apple has developed some standards so that it's not all crazy. They use 800 for low-priority generic drivers and 2000 for specific drivers, at least in the disk storage driver.
Click to expand...

Temptin said:
This is my last post at MacRumors. Everything to be said has been discussed now. Great work everyone! We won. We have official TRIM and it'll only get better with time. :)
Click to expand...

That's what I thought too, but I felt like there probably was some reasoning behind number choices, but apparently not. Do you know if there are any upper limits though? Or lower limits if not 0?

Wait hold on.... You're actually leaving, or was that a joke? Don't go, you seem smart!
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back