Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.mac.system > #59663

Re: SSD in Older MB Pro?

Show all headers | View raw

> > 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

Back to comp.sys.mac.system | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

SSD in Older MB Pro? Davoud <star@sky.net> - 2014-05-22 19:22 -0400
  Re: SSD in Older MB Pro? dempson@actrix.gen.nz (David Empson) - 2014-05-23 13:03 +1200
    Re: SSD in Older MB Pro? Davoud <star@sky.net> - 2014-05-22 21:24 -0400
      Re: SSD in Older MB Pro? dempson@actrix.gen.nz (David Empson) - 2014-05-23 19:38 +1200
    Re: SSD in Older MB Pro? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-05-23 02:52 +0000
      Re: SSD in Older MB Pro? billy@MIX.COM - 2014-05-23 04:50 +0000
        Re: SSD in Older MB Pro? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-05-23 07:05 +0000
          Re: SSD in Older MB Pro? billy@MIX.COM - 2014-05-23 12:07 +0000
    Re: SSD in Older MB Pro? billy@MIX.COM - 2014-05-23 04:20 +0000
      Re: SSD in Older MB Pro? billy@MIX.COM - 2014-05-24 00:38 +0000
  Re: SSD in Older MB Pro? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-05-23 02:51 +0000

csiph-web