- Jun 30, 2004
- 16,355
- 1,894
- 126
I should be able to work through this with some trouble, but with a resource like the Anandtech forums, I thought I'd explain the situation and get some feedback before I get started. It might save some of the headache.
I gave my brother my ASUS P4P800 "Standard" system for Xmas 2005. [Call me "Brother #1.] I built it in July, '04, upgrading the original 2.4C P4 processor to a 3.0C in October, '04. The memory modules were OCZ EL Gold DDR500 dual-channel. I was able to OC the system to 3.6 Ghz and (DDR) 480 Mhz. It had a RAID0 array with two 80 GB Hitachi drives, with the AGP/PCI ratio fixed at 66/33. It ran perfectly through the point where I decided to make an Xmas gift of it.
You see, our other brother [#3] doesn't make a lot of money, lives in a mountain cabin, and although computer-savvy, didn't have a computer. So we were playing a "round-robin" hand-me-down game, where we gave brother #3 the computer that brother #2 replaced with the P4P800 system. As of January, '06, Bro's #2 and #3 were happier than pigs in poop.
I told brother #2 that his upstairs office was a bit warm, and that maybe we should drop the clock speeds, but it was running fine, and he wanted it running at 3.6 Ghz. So here we are, a year-and-a-half later after Xmas, 2005. Brother #2 calls me on the phone: "I've had a major malfunction."
The system would not complete its post at boot-up. It would hang at "Checking NVRam," just before the odometer clicks through the 1 GB of the dual-channel OCZ memory. The first time it happened today (precipitating the phone call from Bro #2), it also posted a message that the CMOS data or settings were "incorrect," and we were able to get into the BIOS setup. It showed all the default settings -- 3 Ghz CPU, memory timings taken from SPD, etc. I methodically changed it back to the settings extant before the failure.
Same thing happened again. We set the BIOS to the stock values again, and the system hung again.
I remember reading a post here at Anandtech where someone had similar symptoms with another machine. The consensus seemed to be "It's the memory, dude!"
I'm thinking it could be the memory, or the memory controller, or the ICH5R SATA controller, or even a corrupt BIOS. It recognizes the RAID array within the BIOS, insofar as it reports the array name that had been created originally. But for one of the IDE settings, the explanatory help screen was incomplete: it stops at the syllable "con" where it should continue with the entire word "configuration."
I've got a spare pair of OCZ Platinum DDR500's, so I can test the memory. If it is the memory controller (therefore the motherboard), we're "up the creek without a paddle," because I doubt there are any P4P800 mobos out there in retail shrink wrap. So I told Bro #2 that with the worst case scenario, we could upgrade to a Conroe E6300 CPU, an ASUS P5B motherboard and a decent pair of DDR2 memory modules -- and that very likely the ICH8R controller would recognize the two disk array so that we wouldn't have to go through the weekend marathon task of reloading software. Of course, there's still the problem of inconsistent chipset drivers, but the RAID array would be intact, so there would be virtually no data loss, even if we have to reload all the software.
Anyone have additional insights on this?
I gave my brother my ASUS P4P800 "Standard" system for Xmas 2005. [Call me "Brother #1.] I built it in July, '04, upgrading the original 2.4C P4 processor to a 3.0C in October, '04. The memory modules were OCZ EL Gold DDR500 dual-channel. I was able to OC the system to 3.6 Ghz and (DDR) 480 Mhz. It had a RAID0 array with two 80 GB Hitachi drives, with the AGP/PCI ratio fixed at 66/33. It ran perfectly through the point where I decided to make an Xmas gift of it.
You see, our other brother [#3] doesn't make a lot of money, lives in a mountain cabin, and although computer-savvy, didn't have a computer. So we were playing a "round-robin" hand-me-down game, where we gave brother #3 the computer that brother #2 replaced with the P4P800 system. As of January, '06, Bro's #2 and #3 were happier than pigs in poop.
I told brother #2 that his upstairs office was a bit warm, and that maybe we should drop the clock speeds, but it was running fine, and he wanted it running at 3.6 Ghz. So here we are, a year-and-a-half later after Xmas, 2005. Brother #2 calls me on the phone: "I've had a major malfunction."
The system would not complete its post at boot-up. It would hang at "Checking NVRam," just before the odometer clicks through the 1 GB of the dual-channel OCZ memory. The first time it happened today (precipitating the phone call from Bro #2), it also posted a message that the CMOS data or settings were "incorrect," and we were able to get into the BIOS setup. It showed all the default settings -- 3 Ghz CPU, memory timings taken from SPD, etc. I methodically changed it back to the settings extant before the failure.
Same thing happened again. We set the BIOS to the stock values again, and the system hung again.
I remember reading a post here at Anandtech where someone had similar symptoms with another machine. The consensus seemed to be "It's the memory, dude!"
I'm thinking it could be the memory, or the memory controller, or the ICH5R SATA controller, or even a corrupt BIOS. It recognizes the RAID array within the BIOS, insofar as it reports the array name that had been created originally. But for one of the IDE settings, the explanatory help screen was incomplete: it stops at the syllable "con" where it should continue with the entire word "configuration."
I've got a spare pair of OCZ Platinum DDR500's, so I can test the memory. If it is the memory controller (therefore the motherboard), we're "up the creek without a paddle," because I doubt there are any P4P800 mobos out there in retail shrink wrap. So I told Bro #2 that with the worst case scenario, we could upgrade to a Conroe E6300 CPU, an ASUS P5B motherboard and a decent pair of DDR2 memory modules -- and that very likely the ICH8R controller would recognize the two disk array so that we wouldn't have to go through the weekend marathon task of reloading software. Of course, there's still the problem of inconsistent chipset drivers, but the RAID array would be intact, so there would be virtually no data loss, even if we have to reload all the software.
Anyone have additional insights on this?
Facebook
Twitter