Signed up just to share my experience and thank Telnet and ENTERPRISE for putting all this together, you guys rock along with everybody else who did this before me to prove it works! I noticed this guide yesterday after reading Anand's latest SSD article where he links it directly (http://www.anandtech.com/storage/sho...spx?i=3747&p=7
) and promptly dropped my work to read up. Don't tell my boss!
I'll start off by saying I have a Gigabyte GA-EP35-DS4 and was concerned by Marcy's report of HDAT2 mangling his drive on an X48-DQ6. I don't readily have access to anything else with SATA support so I chose to go the Live CD/hdparm route (as per Spacedust's instructions). Having never actually used Linux outside of an SSH connection into some game servers I can assure anybody that's comfortable with a terminal window that it's rather straightforward.
Before I did anything, I didn't want to lose my current Windows install so I backed up an image using Clonezilla. I'd recommend this, it's simple and quick and can save you a headache later if something goes wrong.
Then, using the HP Format utility I put the modified iSSDFUT.exe file on a USB drive. This was something I've done before for BIOS updates and was no problem, the directions in the OP are spot on along with the provided links. I unplugged all other hard drives in my system (leaving them connected confused the updater for some reason) and the firmware installed just fine even with AHCI enabled. Went back into Windows to make sure everything was still there and confirm the update, it installed "New hardware" and asked for a reboot so I knew things were looking up.
Next I booted off the CentOS 5.4 Live CD (had to use the i386 edition even though my computer is x64) and installed the newest hdparm as described. This is where I started to run into issues, but some tinkering eventually got it to go.
The first problem I ran across was that hdparm's -I and --dco-identify commands (to verify my controller was recognized and I had the correct drive) were failing with an I/O error. This was resolved by disabling AHCI and SATA Native Mode in my BIOS.
The next problem was that --dco-restore was failing with a similar error, which turned out to be the same HPA problem mentioned here. hdparm -N was telling me that the sectors were at 78122887 available out of 78125000 total, so I did hdparm -N78125000 to temporarily free them up and disable HPA. After this I was able to --dco-restore successfully. I tried --dco-identify once more to see if it would list DSM under SATA Feature Sets in addition to NCQ and SSP, but no dice; maybe a bug in hdparm? Rebooting my computer restored the previous HPA settings, -Np would make the change permanent but it's only 1MB and I didn't want to risk it.
I then changed everything in my BIOS back to how it should be for Windows, and it booted right up. The difference is insane and I made sure to run benches before and after to confirm the results and demonstrate the benefits.
Here's Crystal Disk Info before I did anything, then after updating the firmware, and finally after enabling TRIM:
Notice that my drive has had hundreds of gigs of writes, without TRIM it was getting pretty sad. I further confirmed TRIM support was enabled with the Intel SSD Toolbox at Word 169 Bit 0 which was now set to 1, as well as with fsutil which told me that DisableDeleteNotify was 0.
Here's Crystal Disk Mark and AS SSD Benchmark before any changes, and after running an Optimizer pass in the modified Intel SSD Toolbox (which took all of 30 seconds):
Look at the increases! Even degraded it was leagues ahead of a mechanical drive, but fixing it up regained my speeds as they were the day I bought it. All without losing any data.
I really don't know what to say, the information on this forum was invaluable. I knew someone would eventually come up with a way to enable TRIM on these drives after Kingston abandoned us and I'm thrilled it was sooner rather than later.
I hope what I've written helps other people to try this for themselves (I've already convinced a friend), it was a scary proposition for me but in the end turned out to be nothing but time well spent. Maybe if this workaround gets enough attention Intel will cave to allow a proper and tested-safe update.