HM77 trim disabled in oprom by intel, but we can mod it and enable it..

Hello,

it looks like the HM77 (m18x-r2 ivy bridge) support TRIM, but TRIM is disabled in the OPROM by intel...
i have read on another forums that people have unlocked the oprom for series 6 e.t.c ..... ( AnandTech Forums - View Single Post - RAID0 trim and SRT seems possible on 6-series and 5-Series )

now to unlock TRIM support on the M18X-R2 it seems we would have to edit offset 1bb22 and add 071E000007 to replace the entry and enable trim on the hm77 raid...

i know that the hm77 as controller ID of 282A and alternativeID of 1E07 that is the number needed and needed to be edited in a oprom...


i do not have the skill knowledge and tools to do so... but i know somebody here probably would!


can anybody mod the OPROM with those info, and merge it into the m18x-r2 bios so i can test if it enable TRIM on the m18x-r2?


thank you!

 

would be great if someone could do this

 

I don't have my ssd's in a RAID configuration but I was under the impression that Alienware updated the embedded OROM in the BIOS to a new version that supported RAID TRIM for the M18XR2. (If you have the R1 then that's a different kettle of fish). If you're using the latest stock BIOS I would think that it works fine. Please correct me if i'm wrong.

Alternatively, if you choose to use an older version / unlocked BIOS then check out the threads over at TechInferno - you should be able to download an unlocked and modded bios that contains the new OROM or get in contact with svl7 to mod the BIOS for you.

 

I believe you are correct on this. The original BIOS with the older OROM did not support it, but TRIM seems to work on my M18xR2 with an unlocked A10 BIOS. SRT (caching) also works, and I think those features go hand-in-hand, don't they?

 

using a trimcheck little utils , it always get negative trim result on C: ( raid 0 )

Code:

TRIM check v0.4 - Written by Vladimir Panteleev
https://github.com/CyberShadow/trimcheck

Loading continuation data from C:\trimcheck-cont.json...
  Drive path   :  \\.\C:
  Offset       :  45350584320
  Random data  :  E0 85 A4 30 A4 88 7B 1D 50 1B 5E C7 60 8D 2F C7...

Reading raw volume data...
  Opening \\.\C:...
  Seeking to position 45350584320...
  Reading 16384 bytes...
  First 16 bytes: E0 85 A4 30 A4 88 7B 1D 50 1B 5E C7 60 8D 2F C7...
Data unchanged.

CONCLUSION: TRIM appears to be NOT WORKING (or has not kicked in yet).

You can re-run this program to test again with the same data block,
or delete trimcheck-cont.json to create a new test file.

Press Enter to exit...

and on my single drive (single MSATA ) i get

Code:

TRIM check v0.4 - Written by Vladimir Panteleev
https://github.com/CyberShadow/trimcheck

Loading continuation data from T:\trimcheck-cont.json...
  Drive path   :  \\.\T:
  Offset       :  30822400
  Random data  :  0D 18 B1 0F 2A C0 F9 9C 7F 31 24 3F AC A4 A4 E2...

Reading raw volume data...
  Opening \\.\T:...
  Seeking to position 30822400...
  Reading 16384 bytes...
  First 16 bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00...
Data is empty (filled with 0x00 bytes).

CONCLUSION: TRIM appears to be WORKING!

Press Enter to exit...

so TRIM does not work in RAID0 it apear. and the reason why, is that intel excluded the mobile chipset ....

 

system, which OROM and IRST driver u have? Trim works for me on my m18x r2 using 11.6 orom (default) and 11.2 IRST driver. I use 3-way raid-0 according to trimcheck.

 

Yeah, SSD TRIM in RAID0 works for me also, but this is ONLY confirmed with Windows 7. TRIM for RAID0 does not seem to work for my system running Windows 8 on exactly the same RAID0 volume. However, the TRIM Check utility might be giving misleading information or misbehaving with Windows 8 somehow. The manual TRIM tool provided by Windows 8 works fine. So, I say this is either a problem with Windows 8 only, TRIM Check, or a combination of the two.

See below... TRIM Check consistently passes with flying colors on the M18xR2 SSD RAID0 under Windows 7. Here an example showing it works with 5 consecutive successful tests. Maybe try the newer version of TRIM Check, as the version you are using is not the latest. http://files.thecybershadow.net/trimcheck/

This is with BIOS A10 (OROM 11.6.0.1702) and RST driver version 11.7.0.1013.

 

well alright,

now it seem's its working

Code:

USAGE: Place this program file on the same drive
you'd like to test TRIM on, and run it.

Press Enter to test drive C:...

Querying C:\ disk space and sector size information...
  C:\ has 512 bytes per sector, and 8 sectors per cluster.
  70441025 out of 187286271 sectors are free.
Generating random target data block (16384 bytes)...
  First 16 bytes: 44 7C 75 33 62 2D 34 20 8B 85 2B 1C 3B 6C CD 03...
Creating C:\Users\carl\Downloads\trimcheck.bin...
Querying file final paths...
  DOS  : \\?\C:\Users\carl\Downloads\trimcheck.bin
  GUID : \\?\Volume{62621d26-d3ca-434a-b507-5b18d0b1bf72}\Users\carl\Downloads\t
rimcheck.bin
  NT   : \Device\HarddiskVolume4\Users\carl\Downloads\trimcheck.bin
  NONE : \Users\carl\Downloads\trimcheck.bin
Writing padding (33554432 bytes)...
Writing data (16384 bytes)...
Writing padding (33554432 bytes)...
Flushing file...
Checking file size...
  Data is located at Virtual Cluster Numbers 8192-8195 within file.
Querying file physical location...
  trimcheck.bin has 9 extents:
    Extent 0: Virtual clusters 0-255 are located at LCN 4431188
    Extent 1: Virtual clusters 256-767 are located at LCN 4104876
    Extent 2: Virtual clusters 768-1791 are located at LCN 11777336
    Extent 3: Virtual clusters 1792-3839 are located at LCN 31688696
    Extent 4: Virtual clusters 3840-8023 are located at LCN 124185700
    Extent 5: Virtual clusters 8024-12047 are located at LCN 5526968
      (this is the extent containing our data)
    Extent 6: Virtual clusters 12048-12095 are located at LCN 25625740
    Extent 7: Virtual clusters 12096-15243 are located at LCN 68252432
    Extent 8: Virtual clusters 15244-17343 are located at LCN 80002184
Closing file.
Saving continuation data to C:\Users\carl\Downloads\trimcheck-cont.json...
Flushing buffers on \\.\C:...
  Opening \\.\C:...
  Flushing buffers...
Deleting file...
Flushing buffers on \\.\C:...
  Opening \\.\C:...
  Flushing buffers...

Test file created and deleted, and continuation data saved.
Do what needs to be done to activate the SSD's TRIM functionality,
and run this program again.
Usually, you just need to wait a bit (around 20 seconds).
Sometimes, a reboot is necessary.

Press Enter to exit...


C:\Users\carl\Downloads>trimcheck-0.6.exe
TRIM check v0.6 - Written by Vladimir Panteleev
https://github.com/CyberShadow/trimcheck

Loading continuation data from C:\Users\carl\Downloads\trimcheck-cont.json...
  Drive path   :  \\.\C:
  Offset       :  22639149056
  Random data  :  44 7C 75 33 62 2D 34 20 8B 85 2B 1C 3B 6C CD 03...

Reading raw volume data...
  Opening \\.\C:...
  Seeking to position 22639149056...
  Reading 16384 bytes...
  First 16 bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00...
Data is empty (filled with 0x00 bytes).

CONCLUSION: TRIM appears to be WORKING!

on windows 8.1

so seem's its fixed now!

 

Hello

On another note, what are you guys using with intel irst for cache mode? anybody tested this thoroughly ? this is very intriguing to me.. cache... where does it cache it if you put it write-through .... anybody using write-back ?



THANK YOU

 

Just for you....

Here is my M18x R2, running 2x Evo 250GB non-RAID disks. It was clear to me that given how BAD they Samsung EVO 250GB disks (TLC) performed in RAID0, that trim simply could not have been working. So I'm surprised to see your trim-checker believes it is. My disks are verified genuine too.

Anyway, whilst in there I fitted an Intel mSATA (SATA-300) 19GB SLC caching SSD. It came from a client workstation, where it didn't perform too well. Seems to work just fine in my machine. Was it possible it wasn't setup correctly? I don't know.

Anyway it is paired with a very slow, year+ old 1TB Seagate hard disk. You can see the boot screen attached, the green star indicates the accelerated disk. All the text you see above, is what you see when you crash, or don't shut down properly - it needs to do some maintenance, before you boot, but takes only 5 seconds or so.

Also, just for you is ATTO benchmark on the accelerated volume. I know it is not the best show of speed for such a technology, but it does show an improvement. The whole disk feels much better, really.

Intel's RST allows for up to 64GB size of cache disk. And if I were buying a new system with only one hard drive space, I wouldn't hesitate to but a 100+ GB mSATA disk in there, so I'd have some over-provisioning space on top of the used 64GB, and then as my main disk, I'd plump for a 2TB+ mechanical disk. Yes I said that - I would consider returning to a mechanical disk again, now that I've tried the caching thing... I imagine with a new SATA-600 mSATA, and increased size, this would be great.

Another thing of interest, you can boot / install an OS to the caching disk, as you would any other mSATA disk, I found out. But that is by the by.

If you are using this on a desktop, with no UPS power (like a battery in the laptop provides), I'd not use it in maximized mode, for data safety between crashes.

Enjoy your screen shots.

 

Brother ErikO is right on the money... Quoting this from another thread... Cached mechanical drives can function crazy fast when cache-accelerated, even running at SATA-2 3.0GB/s speed. If you don't have a place for a caching SSD, you can use a program like PrimoCache.