Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!nntp.club.cc.cmu.edu!micro-heart-of-gold.mit.edu!bloom-beacon.mit.edu!bloom-beacon.mit.edu!panix!MIX!Blackbird From: billy@MIX.COM Newsgroups: comp.sys.mac.system Subject: Re: SSD in Older MB Pro? Date: Sat, 24 May 2014 00:38:44 +0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Lines: 140 Message-ID: References: <220520141922071255%star@sky.net> <1lm3ng6.1hgq6we12ms8rdN%dempson@actrix.gen.nz> NNTP-Posting-Host: panix5.panix.com X-Trace: reader2.panix.com 1400891924 26202 166.84.1.5 (24 May 2014 00:38:44 GMT) X-Complaints-To: abuse@panix.com NNTP-Posting-Date: Sat, 24 May 2014 00:38:44 +0000 (UTC) Xref: csiph.com comp.sys.mac.system:59663 > > http://www.cindori.org/software/trimenabler/ > https://digitaldj.net/blog/2011/11/17/trim-enabler-for-os-x-lion-mountain-lion-mavericks/ [digitaldj.net/2011/07/21/trim-enabler-for-lion/ via Archive.ORG] http://preview.tinyurl.com/oqdz962 Oskar Groth August 27, 2011 at 9:01 PM This script simply changes some data at an certain adress. If the adress changes in a system update (which it did in Lion), this script will overwrite the wrong data in the kext and probably corrupt it. I pointed this out in my comments when you presented the script. Not really the definition of safe. Yeah I accused you of spreading fear, because you based your assumption that my patch was dangerous on zero facts. Sure, you should not use old kexts. But I made sure the patch had thourough testing in Lion before I said "Ok, you can use it in Lion". And guess what... No one have had any problems (that were not related to the trim itself not working optimally for all drives). It could very well have been a bad idea, but I did not make any recommendations before I could see it actually worked. The reason I did not just update Trim Enabler with a Lion kext is because kexts are actually illegal to spread, so I want to push for a kext-free ultimate solution so I can get rid of it from my servers. The new app (which does a lot more then just enable trim) will probably be out in a week or two. Grant Pannell August 28, 2011 at 1:22 AM Get your damned facts straight. You clearly show absolutely no understanding of the commands presented. If you had any understanding of how OSX kernel extensions actually worked, maybe you'd understand. I explained why your method was unsafe in the post you deleted...but in case you missed it, here it is again. Firstly, the command DOES NOT patch a specific address. It searches for the string "APPLE SSD" and sets it to null bytes (0x00). If the string "APPLE SSD" is not present, nothing will happen. The script will not touch the file. If you run the patch more than once, again, nothing will happen because the string is not present. If a system update occurs, the kernel extension will revert back to original (i.e. no TRIM support). Applying the patch on a new version of the file, that might have a slightly different offset will likely have no disastrous effects. This is because: a) If "APPLE SSD" does not exist in the file, THE FILE WILL REMAIN INTACT. It WILL NOT become corrupt. b) If "APPLE SSD" no longer triggers TRIM support, no harm done. It's just a string. We're not patching assembly code to perform a different task (i.e. jump to address or NOP instructions). We're not patching static addresses in the file either, like what you're falsely claiming. If ANYTHING, patching the string may have an effect on Apple specific SSDs, who shouldn't be using the patch anyway! Secondly, I wasn't spreading fear. I was spreading the truth and the danger in using old kernel extensions with newer ones. I explained exactly why in the post you deleted. Here it is again: a) The kernel extension you were REPLACING is a base extension. There are many other kernel extensions that DEPEND on the one replaced. b) Since there are so many dependencies, you have no idea how these other extensions will react when replacing it with an older version. c) Kernel extensions are linked against specific kernel versions. Lion has a new version of the kernel which is undoubtedly significantly different from Snow Leopard. In fact, if you go back and look at the comments on this post, forums that ignorantly suggest your enabler, and hell, even your own post, there are a ton of people having delayed I/O problems: the good ol' spinning beach ball. There have been a ton of people claiming that reverting the change fixes the problem, yet you have seemed to ignore it. These are the exactly the sort of problems you expect to face when downgrading a kernel extension. You simply cannot claim to have tested it in Lion. There are too many hardware configurations to claim that downgrading a highly dependent kernel extension is safe. Thirdly, you claim the address of the patch changes between system updates. While this is true, the command to enable TRIM has not changed since it's introduction in 10.6.8. It has ALWAYS been to patch out the string "APPLE SSD" and this command has NEVER patched at a specific address. Fourthly, I simply cannot understand how it takes more than a couple of hours to release a tool to run a couple of simple commands....unless you don't really understand how the patch works to begin with. Hell, someone has even commented on this post with a more friendly step-by-step script. I have presented the 'raw' way of doing it, the way that can be adapted for future version of the kernel extension without fucking things up. Surely if you've realized that distributing an Apple kernel extension is illegal, you'd want to quickly replace it with an application that runs a couple of commands. Oskar Groth August 28, 2011 at 2:36 AM Granted I don't know perl well, I based my claim on that when I tried it with SL kext (where 'APPLE SSD' is at a different position), 'APPLE SSD' remains. How come it does not work with SL kext if it just searches for the string? Yeah some people reported problems with beach ball, and problems disappearing when reverting to No Trim. But since it's still the same kext, I ruled out the kext as the issue... Sorry if I came out as arrogant. If one does have problems with Trim Enabler in 10.7.1 _both with and without Trim enabled_, replacing with 2.0 kext and using this script might be a good idea. I just have not seen any such reports yet. Anyway I will try to have the new app ready before 10.7.2. And no I am not spending time on making a script just for trim, I want to make a general SSD utility, display smart info etc. Grant Pannell August 28, 2011 at 3:10 AM In the case of the exact command above, Perl looks for 9 characters (APPLE SSD is 9 characters) between the string "Rotational" (\x52\x6F \x74\x61\x74\x69\x6F\x6E\x61\x6C\x00) and "Q", the start of the next string (\x00\x51). I have not looked at the 10.6.8 kext for some time, and I don't have access to a copy at the moment. As for explanations I can only think of two. Either the command has not been run as sudo and therefore not touching the file OR, the 10.6.8 kext contains an instance of "APPLE SSD" that is not between "Rotational" and "Q" and does not need to be replaced to enable TRIM. -- sub #'9+1 ,r0 ; convert ascii byte add #9.+1 ,r0 ; to an integer bcc 20$ ; not a number