I'm building a second system based on the components I built on two weeks ago, which include Gigabyte GA-P35-DQ6 and a pair of WD 500GB SATA drives, to name the affected components.
This time, based on reading that Windows 2000/XP is supposedly AHCI-capable, I went ahead and enabled it in the BIOS from the start of things after basic system check before installing an OS.
Windows Setup was doing its thing, that is, until I selected a drive to partition. At that point Setup terminated with the error "unable to find any drives". No problem, so I thought. I'll just disable AHCI and restart installation.
That's when my troubles began... The very next time I tried to boot the system, it would hang at "verifying DMI pool data" and >ASCI 127 characters would appear in random places on the screen.
I Googled the problem and read everything from bad floppy drives to bad hard drives to bad motherboard. Oh boy... I contemplatedd the possibility of an "infant mortality" failure and the prospect of an RMA.
Not being one to give up easily, I disconnected any hardware that wasn't required for BIOS POST. That included the hard drives. As soon as BOTH hard drives were disconnected, the system would POST and get past the DMI pool message and then complain about no disc. Now we're getting somewhere, I thought.
Next step was to reconnect one drive at a time and see which drive "failed". After exhaustive testing and rebooting with one and then the other drive, the problem persisted. Could BOTH drives have failed at the same time? Unlikely, I thought.
So I continue troubleshooting. Now I'm thinking it's either a bad motherboard or a power supply issue. So I moved the drives from the Gigabyte controller to the Intel controller connectors and rebooted. Once again, the problem persisted. Hmmm.. now what are the odds both controller chips are bad? Very slim.
After that, I figured it HAD to be a power problem, so I got out my DVM and measured 4.95, 12.04 and 3.29 volts on the red, yellow and orange wires going to the drives. Power's good--very much dead on spec.
So I Google some more, and finally run across something to do with corrupt master boot records. Some folks were fixing the hang on DMI pool with FDISK /MBR, from a DOS boot floppy.
So I tried it. With both drives connected. Then I rebooted. I got a slightly different hang--different "junk" characters displayed than usual. So I disconnected the second drive and rebooted. Now it booted into Windows setup. Ahah! That means I need to have only ONE disc in the system when I fix MBR. FDISK can't select which drive to fix, so the key is to have only one drive in the system. So I unplugged the first drive and ran FDISK /MBR again. Then I found I was able to boot into Windows Setup.
Here's what I think happened:
Contrary to what I read on the net, Windows XP setup does not natively understand AHCI protocol, so when it looked for the available drives, it could not find them, but this error was NOT non-destructive. Windows managed to corrupt the MBR on all drives attached to the controller that was in AHCI mode, causing the system to hang during DMI pool verification. The fix was to set up legacy IDE mode and fix the MBR on all attached hard disks, THEN installed Windows.
So if you are setting up a new system with AHCI-capable controllers, DO NOT enable it until you have Windows installed and then your motherboard chipset drivers for AHCI installed. Trying to jump the gun and be too advanced for the situation caused me a two-hour delay in setting up this machine, due to the inexplicable hang. Keep it simple, add the fancy stuff later, AFTER the drivers are installed.
This time, based on reading that Windows 2000/XP is supposedly AHCI-capable, I went ahead and enabled it in the BIOS from the start of things after basic system check before installing an OS.
Windows Setup was doing its thing, that is, until I selected a drive to partition. At that point Setup terminated with the error "unable to find any drives". No problem, so I thought. I'll just disable AHCI and restart installation.
That's when my troubles began... The very next time I tried to boot the system, it would hang at "verifying DMI pool data" and >ASCI 127 characters would appear in random places on the screen.
I Googled the problem and read everything from bad floppy drives to bad hard drives to bad motherboard. Oh boy... I contemplatedd the possibility of an "infant mortality" failure and the prospect of an RMA.
Not being one to give up easily, I disconnected any hardware that wasn't required for BIOS POST. That included the hard drives. As soon as BOTH hard drives were disconnected, the system would POST and get past the DMI pool message and then complain about no disc. Now we're getting somewhere, I thought.
Next step was to reconnect one drive at a time and see which drive "failed". After exhaustive testing and rebooting with one and then the other drive, the problem persisted. Could BOTH drives have failed at the same time? Unlikely, I thought.
So I continue troubleshooting. Now I'm thinking it's either a bad motherboard or a power supply issue. So I moved the drives from the Gigabyte controller to the Intel controller connectors and rebooted. Once again, the problem persisted. Hmmm.. now what are the odds both controller chips are bad? Very slim.
After that, I figured it HAD to be a power problem, so I got out my DVM and measured 4.95, 12.04 and 3.29 volts on the red, yellow and orange wires going to the drives. Power's good--very much dead on spec.
So I Google some more, and finally run across something to do with corrupt master boot records. Some folks were fixing the hang on DMI pool with FDISK /MBR, from a DOS boot floppy.
So I tried it. With both drives connected. Then I rebooted. I got a slightly different hang--different "junk" characters displayed than usual. So I disconnected the second drive and rebooted. Now it booted into Windows setup. Ahah! That means I need to have only ONE disc in the system when I fix MBR. FDISK can't select which drive to fix, so the key is to have only one drive in the system. So I unplugged the first drive and ran FDISK /MBR again. Then I found I was able to boot into Windows Setup.
Here's what I think happened:
Contrary to what I read on the net, Windows XP setup does not natively understand AHCI protocol, so when it looked for the available drives, it could not find them, but this error was NOT non-destructive. Windows managed to corrupt the MBR on all drives attached to the controller that was in AHCI mode, causing the system to hang during DMI pool verification. The fix was to set up legacy IDE mode and fix the MBR on all attached hard disks, THEN installed Windows.
So if you are setting up a new system with AHCI-capable controllers, DO NOT enable it until you have Windows installed and then your motherboard chipset drivers for AHCI installed. Trying to jump the gun and be too advanced for the situation caused me a two-hour delay in setting up this machine, due to the inexplicable hang. Keep it simple, add the fancy stuff later, AFTER the drivers are installed.