Salient Soft

I had some issues when upgrading to windows 10 – when sleeping/waking I sometimes got a blue screen error which forced an immediate reboot. I was running bios revision F18, so elected to upgrade to the latest non-beta version which was F22 at the time.

Reflashing was fine using qflash straight from the bios having placed the new bios image on a flash drive. It was also safe as the motherboard was dual bios so wouldn’t brick itself if I accidentally had a power fail whilst flashing.

However, Windows 10 would not boot after the reflash. The reflash reset all motherboard settings to default, so after some investigation I noticed that the Peripherals, SATA mode selection was set to IDE rather than AHCI, the latter being required by Windows 10 (and also used by my Windows 7 installation previously). Changing this allowed the system to safely reboot, only needing a slight repair fix by windows which took only a few seconds. All was then well. I had also tried to set the OS type to “Win 8” rather than the default of “Other”, but this was in fact a red herring – not sure what this setting does exactly (claims to allow certain Windows 8 features but does not elaborate), so in the end I just left the setting at “Other”.

This fixed the issue. 

Comments Off on Windows 10 Boot issue after Gigabyte GA-Z77-D3H reflash to F22

This was done in order to resolve ongoing reliability issues with the OCZ Vertex and SATA port errors from the P6T as detailed here.

This post also follows on from my earlier post here concerning hot swap issues, where I went into some detail of the P6T flashing process. Reference should be made to that post for more details of P6T flashing.

The following steps were performed:-

1. I identified the current firmware version of my OCZ Vertex. To do this start device manager, find the disk under Disk drives, and open its properties. Then select the Harware Ids property and the version number of the firmware will be shown. There were hints in the forums of a more detailed revision number, but I could not find it. My initial version was 1.5.
2. I also tried to run the OCZ Toolbox which allows identification and upgrade of the firmware, and also auto downloads the correct new version. I nice idea if it had worked! In my case it failed to find the OCZ Vertex either before or after the upgrade process.
3. I did note that a number of posts suggested switching the SATA mode to AHCI in both the bios and windows. This OCZ post details the process, which (for the windows part) simply involves changing the value of HKLM\System\CurrentControlSet\Services\msahci\Start in the registry from 3 (=IDE mode) to 0 (= AHCI mode). However, when I tried this at this stage, the system froze at boot time. Fortunately, I was able to switch the setting back in the BIOS, boot into safe mode, and set the registry setting back to 3, to restore the system to a working state.
4. The latest version for my Vertex was 1.7, but it is not possible to upgrade directly from 1.5 to 1.7. It is necessary to upgrade to 1.6 first. Finding all the historical versions of the firmware is not easy on the OCZ site – the main download area only has the most recent version. Older version may be found from a forum post here which has all the historical downloads.
5. For my Vertex, here is  the 1.6 upgrade and here is the 1.7 upgrade.
6. Note that as per the 1.6 upgrade, I had the ‘filename error’ which meant that I had an older version which needed a destructive upgrade to 1.6 due to a change in the NAND/wear levelling algorithm. This would mean loss of all data on the drive and a restore afterwards, and the use of a different kit for upgrading. The upgrade also could not be done with the drive in use as the system disk. The links in the previous paragraph give all the instructions and the alternative versions of the upgrade.
7. I then made 2 full backups with Acronis, plus another daily file backup, to be sure I would be able to restore the drive.
8. As per the instructions, I jumpered the drive to set it into standalone/upgrade mode, and booted from the previous version of Windows 7 which I still had available on a standard Hard drive. I kept this available just in case, and on this occasion I was very glad I did.
9. The destructive upgrade is available as 16_win_vertex.zip. Unfortunately the zip contains 2 versions of the update, 641102VTX.exe and 661102VTXR.exe. There are no release notes to say which version to use or what they are (!) I wondered if they related to the internal firmware/drive version from which you were upgrading, but I didn’t know that either as I have said earlier. Another forum post hinted that as may be expected, the 661102VTXR.exe was a later version and the ’R’ indicated revised. I decided to try this one.
10. Having jumpered and rebooted, the drive correctly identified itself as YATAPDONG BAREFOOT, and I proceeded with the upgrade, which went successfully.
11. I then immediately upgraded from 1.6 to 1.7 using 17_updaters_1.zip.  This time, a standard non-destructive upgrade could be done (not that it mattered in my case), which mean burning an ISO on a CD, and booting that to do the upgrade. The zip contained ISOs for a number of OCZ products plus some release notes this time, so I burnt the ISO for the Vertex. I booted it and did the upgrade, which went with no problems. One point is that I cannot recall whether I removed the jumper on the drive before or after this final upgrade. I am fairly sure that it was after, in which case the upgrade does not mind whether the jumper is present, but if there are any issues it should be tried without the jumper present as would be normal for a non destructive upgrade.
12. Following this, I booted the system. Initially it could not see the Vertex, so I rebooted into the bios, found it was then visible, and did a bios save and another reboot. This time the drive was visible but not formatted.
13. I then booted Acronis from its rescue CD and restored the backup, plus the Master Boot Record. This proceeded normally.
14. After rebooting, the system came up and ran fine, however it did present the boot manager from the other disk, and the system had to be selected from there. To prevent the need for this, I copied the boot files back to the new SSD using bcdboot as per this post here. It was also necessary to reset the boot order in the bios so that the SSD was chosen first, otherwise the boot manager is still presented even after you have run bcdboot.

Now I had a working system with the updated SSD, I decided to reflash the P6T as well. Previously I had had hot swap and SATA issues with later bios versions, as detail here. However, since then I had disabled the onboard JMicron controller which was giving problems, and replaced it with a Startech controller, as detailed in the update to this post here. Therefore, the original issues which were preventing the use of a later bios were no longer present, so I opted to flash to the latest version which at the time of upgrade was version 1408 :-

1. I used the in-bios EZ-Flash, and the process and precautions are detailed in the original section of this post here.
2. I re-applied the required motherboard settings as per the process, and rebooted successfully.
3. I then retried switching into AHCI mode, as detail above when I tried it prior to the upgrade. This time it worked correctly with no problems. In the bios, I just set the onboard SATA to AHCI. The JMicron controller was disabled, and the Startech controller was not touched as this was an add-in card just used for SATA backups. It is possible that now either the onboard ICH10 SATA or JMicron SATA might work and hot swap reliably in eSATA mode with AHCI enabled, but as I was happy enough with the Startech I decided to leave this issue well alone for now.
4. As a final test, I re-ran the Windows Experience tests to see if AHCI had improved performance, and indeed the primary hard disk figure had increased from 7.1 to 7.3, which is good considering the fact that my original OCZ Vertex is now an old  technology which has been set to End-Of-Life by OCZ. The system certainly felt snappier, but this is highly subjective as I had not run before and after benchmarks – the goal of the whole excercise was reliability rather than speed.

No Comments »

Update 24/3/2011 09:08

The event log reported an error on boot today (after a very slow boot with a long blank screen), seemingly for SATA 3 again (unless I am still confused about how the port mapping works)!

The driver detected a controller error on \Device\Ide\IdePort2

This is very strange as SATA 3 is no longer connected, so it appeared to be winging about an unused port. It is possible that Windows interrogated the port on boot and got an error even though nothing was connected, but it is still a bit weird. No immediate action has been taken – will monitor over the next few weeks.

The next step would probably be to add a new PCI express SATA controller and disable all the onboard SATA completely. This Startech controller offers 4 internal and 2 external ports, and needs a pci express X4 slot. It would therefore fit in the spare pci express X16 slot in my P6T, as pci express cards with less lanes can fit happily in a larger slot and use it partially. At the time of writing it is available from Lambdatek for around £66 inc VAT. It appears to get very mixed reviews, although my experience with startech has been good. A search did not reveal any other obvious cadidates for a reasonable price – just some higher end raid ones which also seem to have fans so hot and noisy as well as pricey!

Update 7/2/2011 12:54

I examined the event log again over the last few weeks and new errors were present for SATA 3:-

Error, Event 11, Atapi – The driver detected a controller error on \Device\Ide\IdePort2

This appears to be a new problem affecting the Samsung 1TB data drive. The drive has therefore been moved to SATA 6 and will be monitored over the next month.
It is still not clear whether these issues are due to one or more faulty cables or to faulty ports on the motherboard. The next test will probably be to swap the cables for new ones and monitor again, as this is much easier and cheaper than a full motherboard swap. Given that a single cause is more likely than multiple independant failures (unless a whole batch of cables were faulty or of poor design), a fault on the motherboard looks most likely for all the issues.
As multiple disks have now been affected (The Vertex and one of the Samsungs), at least it does not appear to be a fault with a particular device.

Update 7/11/2010 8:33

I examined the event log and the drive error has not occurred since before moving the cable to port SATA 5 (last occurrence of error was 2/11/2010 at 9:51)
Therefore my conclusion is that either port SATA 1 on the motherboard is faulty, or there was a poor connection, or a faulty cable issue which has been rectified when the cable was moved.

I may try some further tests – perhaps moving back to port SATA 1 with a new cable to further narrow down the issue.
I will check again in a couple of weeks for any errors and perhaps try a further test then.

The good news is that the evidence does not point to a faulty OCZ Vertex drive.

I have had occasional drive errors logged, as follows :-

Error, Event 11, Atapi – The driver detected a controller error on \Device\Ide\IdePort0.

It appears that this error relates to SATA 1, the OCZ Vertex, although the mapping between the event and the actual disk is hard to establish. There are Microsoft posts on how to do this here and here, however they do not use the same disk/port designation as above so they are not all that helpful.

The problem could be the drive, the motherboard controller, or the cable. To start to diagnose it, as at 12 noon on 2/11/2010 I have moved the OCZ Vertex onto Port SATA 5 with the same cable. I will monitor the issue and try further diagnosis over the next few days/weeks and post the outcomes here.

IF I do have to replace the existing OCZ Vertex (should be under warranty though…) there is now a Vertex 2 which is faster, and also a Vertex 2e which reduces the overprovisioning in the SSD. This overprovisioning is the area used for read-modify-writes/block cleaning where a block is swapped for one in the overprovisioning area. It is also used for wear levelling and bad block replacement. See here and here for for a discussion by AnandTech on this. See here for a  review of the Vertex 2e and comparisons with the Vertex 2.

No Comments »