Was over at a friend's house tonight to help him o/c his main system. He has what I think is an Athlon 3000. I get this from the 200 x 9 clock speed. Not sure if it is common to see this chip in a desktop. His board is a Gigabyte socket 939 with the Award F4 BIOS. The mult. is locked at 9, so we had to primarily play with HT freq.
Set the HT link mult. and memory divider back, and then took the chip through 220 and 235 base freq. on stock volts. Booting Windows on diagnostic mode. Seemed stable enough. He got itchy then, and wanted to take it to 245, so we did.
POSTed, and booted into Windows, but while the desktop was loading the graphics came up corrupted, and the system restarted. I figured we needed to give it a shot of voltage. Went into setup and bumped it from the stock 1.40 to 1.425. Restarted.
Ooh, fun... missing or corrupt hal.dll. Not good. Booted from the CD and entered repair console. Did a dir on C: and got about the top 1/3 of the directories, and then a message "Error enumerating directories."
Oh, really not good. Ran chkdsk, and it said it was performing special recovery. After it finished we could see all the directories again, and were hopeful we had it. Rebooted. Made it through the scrolling bar start screen, and then the system went off into lala land for a long time before bsod'ing.
Back into repair console. Did a chkdsk /p /r. Chkdsk ran forever, and when it was done reported that it had fixed one error. Rebooted, same issue. At this point we swapped hard disks and booted off another drive. Luckily all the files he cared about were still intact on the first drive, but Windows was really foobar'd. There were two huge files at the bottom of the \windows directory with long (wider than the display), strange names, and .bak extensions.
Anyway, he can recover, but I was curious as to whether you guys think this was caused by the usual processor failure in an o/c scenario, or perhaps the SATA port wasn't locked? I'm not sure how to tell if it is or not. The drive was in SATA0 on the board, if that helps.
Set the HT link mult. and memory divider back, and then took the chip through 220 and 235 base freq. on stock volts. Booting Windows on diagnostic mode. Seemed stable enough. He got itchy then, and wanted to take it to 245, so we did.
POSTed, and booted into Windows, but while the desktop was loading the graphics came up corrupted, and the system restarted. I figured we needed to give it a shot of voltage. Went into setup and bumped it from the stock 1.40 to 1.425. Restarted.
Ooh, fun... missing or corrupt hal.dll. Not good. Booted from the CD and entered repair console. Did a dir on C: and got about the top 1/3 of the directories, and then a message "Error enumerating directories."
Oh, really not good. Ran chkdsk, and it said it was performing special recovery. After it finished we could see all the directories again, and were hopeful we had it. Rebooted. Made it through the scrolling bar start screen, and then the system went off into lala land for a long time before bsod'ing.
Back into repair console. Did a chkdsk /p /r. Chkdsk ran forever, and when it was done reported that it had fixed one error. Rebooted, same issue. At this point we swapped hard disks and booted off another drive. Luckily all the files he cared about were still intact on the first drive, but Windows was really foobar'd. There were two huge files at the bottom of the \windows directory with long (wider than the display), strange names, and .bak extensions.
Anyway, he can recover, but I was curious as to whether you guys think this was caused by the usual processor failure in an o/c scenario, or perhaps the SATA port wasn't locked? I'm not sure how to tell if it is or not. The drive was in SATA0 on the board, if that helps.
Facebook
Twitter