This message doesn’t automaticly mean, that TRIM doesn’t pass through the Intel RAID Controller into the RAID0 array.
Since the TrimCheck Tool is not able to detect very low TRIM activities, you may have to trigger TRIM before you execute the tool.
If the tool should still give you the message, that TRIM "appears to be not working", I recommend to do the manual TRIM test by using an Hex Editor like HxD.
For details please read carefully the start post of >this< thread.
Done the hex JPG test, deleted the JPG, the hex code was still there so TRIM does not work…
I am still unsure about that.
Question: Have you triggered TRIM before doing the test?
By the way: Corsair GT SSDs have a Sandforce Controller, which is very tricky regarding TRIM support. That means, that the detection of any TRIM activity is not easy at all.
I have not triggered TRIM before the test, just checked if it’s active (DisableDeleteNotify=0)
I have successfully verified trim as working before, on the same Corsairs, using Panteleev’s trimcheck
after doing your recommended steps for altering the original BIOS, when running Win7 Ultimate x64.
You should repeat the test after having triggered TRIM.
This verifies, that the TRIM command passes through the Intel SATA RAID Controller into the RAID0 array.
So the problem is not to find out, whether TRIM works within the RAID0, but whether its activity is strong enough to detect it.
I don’t think, that your current problem to detect TRIM activity has anything to do with the recently done BIOS modification or the in-use Intel RAID driver version.
How do I trigger TRIM?
Is it not enough to delete a file to initiate a TRIM command to the SSD?
If you would have read the post, which I had linked for you >here<, you would already know the answer.
No, if there is no TRIM activity.
Sorry for the incomplete reading (I ignored the parts that referred specifically to Win7/8).
I have tried the Anvil Pro, triggered TRIM before using trimcheck, and got the same result: trim not working…
When I first did the mod following your instructions, a few years ago under Windows 7 Ultimate x64, trimcheck
worked like a charm from the first time - and everytime.
I’m using trimcheck x64 0.7 version. I will try the x86 version too.
LATER EDIT: tried the x86 version, same results…
So you mean, that it is the OS Win10, which prevents, that TRIM passes the Intel RAID Controller into the RAID array?
If that would be true, we would have heard about such issue.
I’m not sure what is the cause - Windows 10 or just an incompatibility of the BIOS’ RAID with the OS and/or the OS RAID drivers…
Is there someone with a P67-based board (Gigabyte GA-P67A-D3-B3 rev. 1.0 in my case), RAID0 SSDs and Windows 10 x64?
I would very much like to know what combination of firmware/drivers works for you…
Went back to Win7Ux64 (got an Acronis backup). I have the same BIOS that I modded for Win10 (trim-modded 12.9.0.2006), but with the old Intel drivers (12.8.0.1016) that were on that backup.
TrimCheck consistently works within 10 seconds, I have tried multiple times.
I guess I’m stuck with Windows 7 for now (Edge browser still felt under construction, so no regrets there).
@ Razvan_N:
Thanks for your interesting report. Since I have absolutely no explanation for your different TRIM in RAID0 results, I would rather like to know the exact reason for them.
If I were you, I would update the Intel RST(e) RAID drivers to v12.9.4.1000 WHQL.
OK, will do that as a scientific effort 
since it works nicely with the old ones…
LATER EDIT: tried with the recommended drivers and it still works. So I guess it’s something wrong with Windows 10…
From reading the original thread on Anandtech there was some discussion that ICH8R/9R/10R parts that do not report an alternate ID would not work for enabling TRIM with a patched OROM. At first it was assumed all ICH “R” parts would not work but that was later solved, this thread (and this one here) explain that. But I didn’t see anything in either thread that confirms/denies if the requirement of a non-zero alternate ID still remains. When I run Dufus/CPL0’s SATA ID Tool on my DX58SO it reports 0 for alternate ID. I don’t want to go through the desoldering process to mod my Intel board only to find it won’t work anyway.
@gyrator :
You can insert any TRIM modded Intel RAID ROM module into the BIOS of your mainboard and you will get TRIM in RAID0 support (provided, that you run an Intel RAID driver from v11.x.x.xxxx up). The “Alternate DeviceID” of your on-board Intel RAID Controller doesn’t matter.
Let me explain why:
Natively the older Intel SATA RAID Controllers do not support TRIM in RAID0, because their “Alternate DeviceIDs” have not been coded by Intel for this feature within the Intel RAID ROM modules. At the beginning of his experiments Dufus/CPL0 thought, that there is no other way to get TRIM in RAID for these older Intel Chipsets by changing the specific hex code for the related “Alternate DeviceID” within the RAID ROM resp. EFI RAID module. This is what he had published in the AnandTech Forum. At that time I modified the Intel RAID ROM modules specificly for certain “Alternate DeviceIDs” to make them “fit” for TRIM in RAID0.
1-2 years later our genius and Forum member Dufus/CPL0 found out, that changing just 1 specific Byte within the Intel RAID ROM or EFI RAID modules enables the TRIM in RAID support for all Intel RAID Controllers, no matter which “Alternate DeviceID” they have.
From that time on there was no need anymore to customize the code of the “Alternative DeviceID” individually for each chipset.
I guess that modding P8H61-M LX R2.0 will not be that easy in order to support RAID since it has UEFi BIOS.
@mrnemanja :
Intel H61 Chipset mainboards generally do not support the Intel RAID option. That is why it is impossible to run any HDD/SSD in RAID mode or to create an Intel RAID array with these mainboards.
By the way: It doesn’t matter, whether the mainboard has a LEGACY or an UEFI BIOS. The problem is the same.
@gyrator
It could be either soldered or within the SPI clamshell socket. It’s located nearby the PCI-Ex slot.
If the chip is inside the clamshell you should pull out the chip and clamp it to the properly configured SOIC8/SOP8 test clip, else just attach it on the disconnected board.
Also, could you upload and send on PM the BIN if you succeed?
I’ve located the chip, it’s soldered (like the first picture).
I’m ordering a flash programmer and test clip today. I’ve been told the test clips are questionable at best but I’m trying that first. Desoldering is a last option.
I’m curious what you would do with the BIN, you need a programmer to flash the chip as well, you can’t use Intel’s flash tools to reprogram with a BIN file, they only work with Intel’s BIO format. And wouldn’t the BIN dump have my MAC and S/N? I would assume those should be scrubbed from dump.
@gyrator
If you dump the bios from the W25X16 I will able to boot in recovery and do the stuff to been able to restore mine “new” super old 202 board, without too much banging. I could eventually succeed even without., unless the board has other issues. To recap: the board I received has no bios, so, I will flash your into mine. (( see: DX-SO-bios-request ) it has the clamshell)
There no mac address or unique serial data unless your is customized with the tools provided by intel, such are ITK and thing related with ODM/OEM.
In any case it’s a simple BIOS like many for other board, other manufacturer release the binary, also, I think it could be done even in the OS, dunno atm, anyway, you can still reprogram the SPI with anything capable to read and write the chip so, be advised to read carefully and understand the programmer guide and the risk involved into attaching the cable to the wrong pin etc etc, etc.
UPDATE: I resurrected the board and also updated the microcode, so, the chip dump is not needed anymore, thanks by the way!