Firmware Update Program does not recognize drives with non-windows partitions

[fedup1664522]

Note topic.

I am starting a new thread for this specific problem, as I think it deserves its own thread.

This problem has been mentioned previously, though buried deep in another forum post:

Orginial Firmware Update Tool Doesnt see SSD

Many people are using other operating systems like Linux and/or non-Windows partitions.

I think it's poor that the firmware updater does not work with drives that have non-Windows partitions, and that the updater does not provide any useful information as to what the problem is.

This is a bug.

G.Skill and/or Sandforce should work proactively to provide an updated firmware update program.

Just telling the customer, "According our experience, if this SSD has others non-windows partitions," does not provide a lot of useful help.

[G.SKILL]

I totally agree with you.

As I said previously, I have already pushed their RD many times about this topic.
I feel sorry for making you guys inconvenience

[laimen]

Cannot see those with windows' partition too

My SSD is a boot drive of Windows 7 x64.
I made it a gpt partition drive, and the update program just doesn't see my SSD anyway.

[fedup1664522]

I'm going to guess that if you force a non-standard C/H/S disk geometry--i.e. not (H)eads=255 and (S)ectors=63--it will give the fabulously non-robust firmware update program a problem.

Are you able to check the partition table to see what geometry it is using?

Somebody (not me) should test this out.

[laimen]

dd the ssd

I finally external dd write zeroes to the drive with Parted Magic,
then the update tool recognizes the drive.
And I updated the firmware to 3.2 successfully. It works properly.

[steveea]

FWIW I just used the boot CD and he 3.2_A FW upgrade on my 120GB pro with only Linux partitions. No problems All partitions are Linux..

I don't know why the Updater should care about the partitioning.

---

One error with the 3.2 firmware
After the update I am getting some bad values for the smartctl parameter #9 Power_on_Hours

From smartctl -I ....

9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 80590766343535
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 90555090470255
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 100777112634735

Note that these values in hex are:
0x494C0000056F
0x525C0000056F
0x5BA80000056F

So it appears that the upper 16 bits are random. The 00056f part increments as expected.