I have a Macbook pro 17 and i had no problems installing the update. After reading the post it looks like there is some issue between the win 7 driver that is installed and the firmware. Lucky for us we don't have to worry about driver issues. Also, your VM does not see your drive as a SSD so there should be no problems. Your VM is emulating a windows drive.
The only bad thing for OSX users is that TRIM is not supported as of yet on OSX.
If it is anything OS related, then it has to be something extreme the newly activated Windows driver does to corrupt fundamental settings in the SSD. If people are unable to even see the partitions, recover a usable one, or are presented with strange SMART errors, this would normally point to a firmware update issue rather than an OS one. It is very odd indeed. Huge sympathies to all affected.
5 reboots and still no issue but it does not stop the concern each time I turn off
Correct. If using Windows 7 with the MSAHCI driver, then you do not need the Toolbox to run Optimizer because it's done natively in the OS.
Please refer to Table 1 (on page 5) of the whitepaper cssd_run refers to in his last post for verification or more information:
So the Optimizer acts like TRIM for those who can't have TRIM? And they run it daily because they don't have TRIM. The Optimizer is essentially a manual version of TRIM. Interesting, and confusing, ;-) I think Intel could have done a better job of explaining that in the User's Guide--not everyone reads the white paper.
Now I still want to know why Windows 7 did not disable Superfetch, prefetch, and ReadyBoost when my SSD got a 7.8 score in Performance Index.
All the posts indicated that they were successful in flashing the drive with the firmware. All the drives were flashed under FREEDOS. Unless somebody has verified outside of the win7 OS that there drive worked before they booted into Windows, then you left with the OS and/or chipset corrupting the drive. What is at issue is that AFTER rebooting and AFTER windows 7 having installed/updated the OS driver, the drive becomes corrupt. This suggest that there is a issue between the win7 driver and/or chipset driver and the firmware.
The fact that your setup works suggest that one, you followed the directions carefully, and two your system setup chipset/driver is compatible with the firmware. I doubt that you will have any problems no matter how many times you reboot. Some of the posters fall in the category of not following directions as stated in the installation even though they will swear up and down that they did and some of the posters have legit issues with the current Intel firmware and their system.
MACs do not have to worry about drivers, etc, setting ahci. I would bet that most if not all mac users will have no problems with the update because of this fact.
For those that think it is STRICTLY a firmware issue, you should hope that this is the case because otherwise Intel could come back and say it is not our problem. SSD technology is still immature and relies on the SSD vendor, chipset/vendor, and Microsoft to make everything it work harmonious in a WIN environment.
I have the 160 GB gen2 and 2 80GB gen 1s and i have had no problems installing in my MAC or on HP computer. And i have had no problems updating the drives with the latest firmwares. The HP computer didn't let me set ahci, ide, etc. It automatically used AHCI.
I hope a solution can be found to fix everyone's problem and that the solution lies with Intel and not a combination of Intel, Microsoft, and/or the motherboard vendors.
This is 100% the firmware problem and 0% user error because the firmware won't allow you to update your drive if the SATA ports are configured incorrectly. Where is there any room for user error in the procedure when the firmware update won't work unless things are set properly. Maybe a person could have powered down or disconnected the drive causing it to corrupt, but this is way too widespread for that to be the case. You don't know what you are talking about trying to push the blame to the end user. Intel has replaced every drive from those who have requested a RMA due to the firmware upgrade, so they are obviusly admitting they did something wrong here. Lets also not ignore that this was their second major screwup with this particular drive, or did everyone all ready forget the BIOS password recall.
dbm, you are quite correct. I was pointing out that it was either the windows driver corrupting things post-1st boot or something in the firmware that does not like the hardware; the latter I struggle to see how it works due the the successful post-firmware boot. It is, in the case of the former, v.extreme for a windows driver to hose the basic settings of a drive and this is the worrying aspect of this issue Post boot-problems are then not OS issues with a driver it seems - they are more fundamental.
Hmm .. wonder if the version of Windows 7 Mine was not the retail but the final MSDN version available for some 4 weeks prior to launch. We know the release one has had changes. I have also had to refuse a LAN driver update from Windows update as it always stops my interface from working. I see someone also had a Windows server 2008 problem with the update.
Yes and no weuntouchable.
The issue appears to arise once you reboot and Windows 7 loads a new driver for the re-flashed drive. It is only then that people have issues at the next reboot. It thus appears to be an issue that the driver initiates and it seems to be this s/w that then hoses the drives.
However, the driver interacts with the firmware so, yes, you can fairly point the finger at the firmware as this is the changed element of the system. However, it is also an MS driver at issue here ... I suspect there are some interesting phone calls between Intel and MS at present.
My working driver is 21/6/2006 : 6.1.7600.16385
It is the same driver all the SATA drives use.
You didn't read my post. I said some users may not have followed directions and some users HAD LEGIT ISSUES. Evidently you didn't read that part.
The reason why they are replacing the drive is because that it is "a good business practice". It does not mean that there is something wrong with their firmware. This is why they pulled the firmware until they can pinpoint what the source of the issue is.
The firmware has to interact with the computer, therefore in your case the Microsoft OS and vendor chipset drivers become variables that need to be eliminated in order to prove that it is a strictly a firmware issue. In order to prove that this is a firmware issue, one would have to upgrade the drive, then check OUTSIDE of the WIN OS that the the firmware was flashed correctly. If the drive was flashed successfully, then that means that the Intel firmware PLUS SOME OTHER VARIABLE, yet to be identified causes corruption.
The question is can Intel fix the issue through their firmware or does it require a microsoft and/or vendor chipset update. i would hesitate to be so smug in thinking that it is strictly an intel issue and then discover that it is a non-intel issue that intel can't fix. This would not be the first time of something like this happening where there is a incompatibility between the WIN OS and a vendors driver/firmware (i.e. audio, video drivers).
You apparently failed to read my post where I said its impossible to upgrade the firmware if the SATA ports settings are not correctly configured in the BIOS. That eliminates any user error aside from unplugging the drive or powering down the system during the upgrade. I'm not saying the firmware in and of itself is bad, I'm simply saying that user error can not be the cause of this widespread failure because Intel idiot proofed the update process by detecting what the SATA port is set to and not allowing the drive to be detected if they are not setup properly.
I personally think the problem is either a bad batch of drives or a driver conflict. I don't think the firmware by itself is bad because then 100% of the drives would be bricking. Its the firmware in combination with some other, at this time unknown, factor.
Quoted from weuntouchable
"You apparently failed to read my post where I said its impossible to upgrade the firmware if the SATA ports settings are not correctly configured in the BIOS."
Very much incorrect. The instructions with the flash tell you to set your drive to IDE mode in your BIOS. A LOT of people including myself did not do so and flashed the drive with no issues with it still in AHCI mode in the BIOS. Some OEM systems dont even have an option in BIOS to change the ports mode. Fortunatley I have not had any problems in the day and half since. Multiple reboots, couple of sleep cycles, etc.
If it matters - my system is a home built.
Abit IP35 Pro motherboard with an ICH9R chipset.
Windows 7 Ultimate x64 RTM from Technet
The ICH9R controller was in AHCI mode all along, Windows 7 had been running with it in AHCI mode for a couple of weeks since I installed it. It booted from the CD I made and flashed just fine. Rebooted, Win 7 hit and automatically installed new drivers for the SSD. Rebooted again since Win 7 asked it to. Been fine since. The toolkit works and everything.
One thing for me though. I had previously installed the Intel chipset inf drivers and those are the drivers on my AHCI Sata controller. They still are and I'm definitley not planning in trying to change it to the original Windows AHCI driver right now as I'm terrified that will probably hose my SSD.