- May 19, 2011
- 19,911
- 14,156
- 136
This is a computer I built back in 2008 for a customer and has undergone two OS upgrades (XP, Win7, Win10) in that time and basically still going strong. 3 years ago the customer complained that the computer was going slow and I presented a few options, they went for the SSD upgrade.
This is one of those times that I should have taken more notes and I would probably have saved myself some time this time around (these days if a job ever goes into the territory of 'non-ideal solutions', I document it)! Evidently I set up the SSD onto the on-board default NVIDIA SATA controller, something I know since then to be a bad idea because Win10 looks at the old 'standard IDE controller', recognises it for what it is and promptly auto-installs the nvidia sata driver (which I've seen before resulting in very long boot times). Some may cry, "disable auto driver installation!", which I reticent to do since I assume it stops Windows from auto-installing pretty much any driver (though I also assume there are exceptions like default USB drivers for say a flash drive).
Anywho, back to last week. I noticed in the defrag utility, "optimisation not available" for the SSD. Hmm, not great, especially since it would be with the default IDE driver. I also noticed that this board has a separate SATA RAID controller (JMB363) and it can be set to AHCI mode. It gets recognised by Windows as a standard AHCI controller. Joy! Why did I not use this last time I wonder. I ended up taking the computer home because it also needs a feature update and that will take a while, plus customer is moving house and would prefer not to have to transport it themselves to the new house. Win win I guess?
I attempted to get Windows to switch to booting the SSD with the RAID controller in AHCI mode (the bcdedit safe mode tweak), and Windows said nah (INACCESSIBLE_BOOT_DEVICE). I considered the possibility that while this board has a RAID controller, it doesn't mean Windows can boot from it, however, if that were the case then it wouldn't have BSOD'd. Digging a little deeper (Windows in recovery mode or in setup mode), diskpart would only report the USB flash drive (if present), and a device with zero capacity (I wasn't sure if this was the CD drive (nothing in it), I suspect it was the JMB controller doing a derp).
I then thought I'd give the JMB363 controller a try in IDE mode and sure enough, long story short, Windows booted fine from it.
However, Windows then decided to throw me a curve-ball: the defrag utility reckoned the drive had been trim'd seven days before. I checked the event log. No other entries except for today (I told Windows to optimise the drive on the spot).
Given the lack of evidence for the 'seven days before', I assume the defrag utility is straight-up lying. Weird though, as I would have thought it get such info from the event log?
PS: When the JMB363 in AHCI mode was doing the derp, I pulled out a PCIE AHCI controller I was saving for such an occasion. The motherboard however wanted none of it: BIOS POSTed just fine, controller info popped up showing the SSD and everything, but it wouldn't get any further than that nor would it let me into the BIOS config with that card installed.
PPS: I also tried the nvidia controller in RAID mode, but it insisted in creating a new RAID volume and I didn't want to nuke the customer's Windows setup.
Overall I hope that connecting the SSD to the JMB363 in IDE mode constitutes an improvement; I mean logically if it's now able to TRIM the drive automatically then it should be an improvement. I could try it in RAID mode but I sincerely doubt that a controller that derps in AHCI mode is going to do AHCI properly in RAID mode
I'm definitely going to document this my usual way
This is one of those times that I should have taken more notes and I would probably have saved myself some time this time around (these days if a job ever goes into the territory of 'non-ideal solutions', I document it)! Evidently I set up the SSD onto the on-board default NVIDIA SATA controller, something I know since then to be a bad idea because Win10 looks at the old 'standard IDE controller', recognises it for what it is and promptly auto-installs the nvidia sata driver (which I've seen before resulting in very long boot times). Some may cry, "disable auto driver installation!", which I reticent to do since I assume it stops Windows from auto-installing pretty much any driver (though I also assume there are exceptions like default USB drivers for say a flash drive).
Anywho, back to last week. I noticed in the defrag utility, "optimisation not available" for the SSD. Hmm, not great, especially since it would be with the default IDE driver. I also noticed that this board has a separate SATA RAID controller (JMB363) and it can be set to AHCI mode. It gets recognised by Windows as a standard AHCI controller. Joy! Why did I not use this last time I wonder. I ended up taking the computer home because it also needs a feature update and that will take a while, plus customer is moving house and would prefer not to have to transport it themselves to the new house. Win win I guess?
I attempted to get Windows to switch to booting the SSD with the RAID controller in AHCI mode (the bcdedit safe mode tweak), and Windows said nah (INACCESSIBLE_BOOT_DEVICE). I considered the possibility that while this board has a RAID controller, it doesn't mean Windows can boot from it, however, if that were the case then it wouldn't have BSOD'd. Digging a little deeper (Windows in recovery mode or in setup mode), diskpart would only report the USB flash drive (if present), and a device with zero capacity (I wasn't sure if this was the CD drive (nothing in it), I suspect it was the JMB controller doing a derp).
I then thought I'd give the JMB363 controller a try in IDE mode and sure enough, long story short, Windows booted fine from it.
However, Windows then decided to throw me a curve-ball: the defrag utility reckoned the drive had been trim'd seven days before. I checked the event log. No other entries except for today (I told Windows to optimise the drive on the spot).
Given the lack of evidence for the 'seven days before', I assume the defrag utility is straight-up lying. Weird though, as I would have thought it get such info from the event log?
PS: When the JMB363 in AHCI mode was doing the derp, I pulled out a PCIE AHCI controller I was saving for such an occasion. The motherboard however wanted none of it: BIOS POSTed just fine, controller info popped up showing the SSD and everything, but it wouldn't get any further than that nor would it let me into the BIOS config with that card installed.
PPS: I also tried the nvidia controller in RAID mode, but it insisted in creating a new RAID volume and I didn't want to nuke the customer's Windows setup.
Overall I hope that connecting the SSD to the JMB363 in IDE mode constitutes an improvement; I mean logically if it's now able to TRIM the drive automatically then it should be an improvement. I could try it in RAID mode but I sincerely doubt that a controller that derps in AHCI mode is going to do AHCI properly in RAID mode
I'm definitely going to document this my usual way