P5V800 stability with Pentium D 920
Bookmark this page:
 Yahoo!
 Google
 Windows Live
 del.icio.us
 digg
 Netscape
|
|
||||||||||||||||
|
Posted by on March 14, 2008, 3:09 pm
Please log in for more thread options --------------------------- Time to chuck this mobo/CPU and start over, or can this be made to work? I put together this setup a couple of years ago, based on an ASUS P5V800-MX board. Last year I upgraded the memory to 1.5 gig Corsair DDR400 and got a Corsair HX520W power supply. I also added a 500 gig Seagate HD planning to replace the old 160 gig (wound up leaving the old one in and switch booting from one to the other as needed). I installed the lastest BIOS. Xp home has all the updates. I have the larger drive setup to boot Linux (Ubuntu) or Xp, and I use them both. The old drive boots Xp. The PC's been running okay with a Celeron D 2.8, although I've never been thrilled with the performance. I just got a used dual core Pentium D 920 cheap on eBay and installed it. As expected, it works a lot faster. I like it. However, it will do a spontaneous reboot if stressed. Unacceptable. This is not an Xp problem because it will do the same thing in Linux -- load up a few resource-hungry applications and start doing things and it will fail. Both cores are working and show activity under Linux and Xp. Good, big Zalman CPU heat sink/fan -- heat doesn't seem to be a prob. Since I've only had the new CPU for a day or so, I'm not ready to give up yet but I can't afford to spend much more time with it. I also can't justify spending much money on it either. I figure if I spent $200 on a new mobo/CPU/Memory combination and sold off the Celeron, the D 920, mobo, and memory for $75 or so, I might justify going out- of-pocket $125. That's what I'm trying to decide right now. Anyone here have an idea about how to stabilize the system? BIOS tweaks, or other tweaks/patches? I need to decide quickly if this can be made to work or not. Thanks in Advance, Alan. I've copied below output from PC Wizard, in case that gives you any clues. ------------------------------------------------------------------- Voltage, Temperature and Fans Hardware Monitoring : ITE IT8712F Voltage CPU : 1.21 V DIMM : 3.28 V +3.3V Voltage : 2.94 V +5V Voltage : 6.85 V +12V Voltage : 11.19 V Chassis Fan : 2657 rpm Processor Temperature : 40 =B0C Mainboard Temperature : 36 =B0C : Hard Disk Monitoring : S.M.A.R.T Hard Disk Temperature ST3500630AS : 48 =B0C Hard Disk Temperature ST3160023A : 45 =B0C System Summary Mainboard : Asus P5V800-MX Chipset : VIA P4M800CE Processor : Intel Pentium XE 920 @ 2800 MHz Physical Memory : 1536 MB Video Card : ATI Technologies Inc Radeon 9600 XT (V350) Hard Disk : ST3160023A (160 GB) Hard Disk : ST3500630AS (500 GB) CD-Rom Drive : PLEXTOR CD-R PX-W1210A DVD-Rom Drive : TOSHIBA DVD-ROM SD-M1302 Monitor Type : ViewSonic PF815 - 20 inches Network Card : VT82C570 MV IDE Controller VT6102 Rhine II Fast Ethernet Adapter Operating System : Microsoft Windows XP Home Edition 5.01.2600 Service Pack 2 DirectX : Version 9.0c LPC bus : Yes PCI Bus : Yes Bus PCI-Express : Yes USB Bus : Yes SMBus/i2c Bus : Yes Bus HyperTransport : Yes Bus CardBus : Yes Bus FireWire : No Processor: General Information : Type : Intel Pentium XE Internal Specification : Intel(R) Pentium(R) D CPU 2.80GHz Model Number : 920 Codename : Presler Revision : B1 Technology : 0.065=B5 CPU ID : F.6.2 CPU IDEx : F.6.2 Microcode : MU0F620F Instructions : IA-64 Technology : No Intel64 (EM64T) : Yes FPU128 : No SSE5 : No SSE4a : No SSE4.2 : No SSE4.1 : No S-SSE3 : No SSE3 : Yes SSE2 : Yes SSE : Yes Extended 3DNow! Technology : No 3DNow! Technology : No 3DNOW Prefetch : No 3DNow! Pro Technology : Yes AMD MMX Technology : No MMX Technology : Yes Cyrix MMX Technology : No CLF - Cache Line Flush : Yes CX8 - CMPXCHG8B : Yes CX16 - CMPXCHG16B : Yes CMOV - Conditionnal Move Inst. : Yes MON - Monitor/Mwait : Yes POPCNT : No RDTSCP : No SEP - Fast System Call : Yes Miscellaneous : XD - No-execute Page : Yes VT - Vanderpool Technology : Yes TXT - Trusted Execution Techn... No SVM - Secure Virtual Machine : No FPU - Co-processor Built-in : Yes FXSR - Fast Float Save & Rest... Yes xTPR - Send Task Priority : Yes DAZ - Denormals Are Zero : Yes FFXSR : No LAHFSAHF : Yes CMPLEGACY : No ALTMOVCR8 : No ExtApicSpace : No 3DNow! Technology : No PBE - Pend. Brk. EN. : No LAHF - LAHF/SAHF Inst. : No ABM : No MASSE - Misaligned SSE : No OSVW - OS Visible Workaround : No IBS : No P1GB - 1GB Page Size : No SKINIT, STGI, DEV : No WDT - Watchdog Timer : No Features : VME - Virtual Mode Ext. : Yes DE - Debugging Extension : Yes PSE - Page Size Extension : Yes TSC - Time Stamp Counter : Yes MSR - Model Specific Registers : Yes PAE - Physical Address Extens... Yes MCE - Machine Check Exception : Yes APIC - Local APIC Built-in : Yes MTRR - Memory Type Range ... Yes PGE - Page Global Enable : Yes MCA - Machine Check Architec... Yes PAT - Page Attribute Table : Yes PSE36 - 36-bit Page Size Exten... Yes PSN - Unique Serial Number : No DS - Debug Trace & EMON Sto... Yes SS - Self Snoop : Yes ACPI - Software Clock Control : Yes TM - Thermal Monitor : Yes TM2 - Thermal Monitor 2 : No EST - Enhanced SpeedStep T... No HTT - Hyper-Threading : Yes SBF - Signal Break on FERR : Yes DSCPL - CPL qualified Debug S... Yes CID - Context ID : Yes LT - LaGrande Technology : No PDCM : Yes DCA - Direct Cache Access : No EPS - Enhanced PowerSaver : No Features Hyper-Threading : Technology : Yes - Disabled Features Multi-Core : Physical Processor #1 (Core #1) : Apic ID 0 Physical Processor #1 (Core #2) : Apic ID 1 Power Status : Digital Thermometer : No Operating Point Protection : No Dynamic FSB : No Dynamic Acceleration : No Addressing Information : Physical Addressing max. : 36-bit Linear Addressing max. : 48-bit Advanced Settings : In Order Queue Depth : 12 Fast-Strings : Yes x87 FPU Opcode : No Thermal Monitor : No Split-Lock : Yes Performance Monitoring : Yes Prefetch Queue : Yes Branch Trace Storage : Yes C1E - Enhanced Halt State : No Temperature Control : 66 =B0C Mainboard Upgradeability : Socket/Slot : LGA 775 Upgrade interface : Unspecified Supported Speed : 2800 MHz (or more) Supported Voltage : 1.2V | ||||||||||||||||
|
Posted by Andrew Smallshaw on March 14, 2008, 4:05 pm
Please log in for more thread options This sounds like a PSU problem. The Pentium D is a considerably greater load than the Celeron it replaced. Looking at the voltages seems to confirm this - none of the key voltages are within the 5% tolerance called for by the spec. Whilst even a 10% variation is usually here nor there, your 5V supply is way above even that. For 5V to be that high suggests that the PSU is overloaded at 3.3V which is consistent with the greater load of the Pentium. Try replacing the PSU with something beefier and see if that resolves the problem. -- Andrew Smallshaw andrews@sdf.lonestar.org | ||||||||||||||||
|
Posted by on March 14, 2008, 7:21 pm
Please log in for more thread options > This sounds like a PSU problem. =A0The Pentium D is a considerably
Thanks, Andrew, for the thoughts. I don't think you are correct, but
> greater load than the Celeron it replaced. Looking at the voltages > seems to confirm this - none of the key voltages are within the 5% > tolerance called for by the spec. =A0Whilst even a 10% variation is > usually here nor there, your 5V supply is way above even that. > For 5V to be that high suggests that the PSU is overloaded at 3.3V > which is consistent with the greater load of the Pentium. =A0Try > replacing the PSU with something beefier and see if that resolves > the problem. > it did help get me going to solve this -- not quite solved though. I have more information ... I called Corsair tech support. The guy was skeptical of the voltages reported by the Windows program. He said the only way to be completely confident with the voltages reported was with a volt meter. However, he also said to look at what it said in the BIOS. I checked there, and the voltages reported were all fine -- very close to spec. 5v was 4.94 and so on. He said the 520 was plenty of power for what I had in my system. They would do the RMA if I wanted but he really didn't think that was the problem. He also suggested running memtest. It turns out that I also have Corsair memory, and I did that. I had run memtest overnight (fine) when I last upgraded the memory a year or so ago. So, I ran it just now and got failures (multiple failures at same address). I pulled out one module (the 512) and ran it again (with the remaining 1 gig module) and found no errors with about 8 minutes of testing. So, I got an RMA on that memory module, and was expecting that it would have solved the prob. Not quite. The system seemed to run better without the offending 512 module, and I was able to load it up with quite a few programs running at once, but I was eventually able to make it fail. The tech support guy also suggested running orthos in safe mode to stress the system. That ran for about 10 minutes before the system failed. So, it's running better, but not totally reliably. I'll run memtest overnight on the 1 gig module. I'm open to suggestions, but leaning toward using it for now (without stressing it too much), and then replacing it (mobo/mem/cpu) soon. Thanks, Alan | ||||||||||||||||
|
Posted by kony on March 14, 2008, 9:49 pm
Please log in for more thread options On Fri, 14 Mar 2008 16:21:30 -0700 (PDT), dechert@gmail.com
wrote: >Thanks, Andrew, for the thoughts. I don't think you are correct, but
>it did help get me going to solve this -- not quite solved though. I >have more information ... > >I called Corsair tech support. The guy was skeptical of the voltages >reported by the Windows program. He said the only way to be >completely confident with the voltages reported was with a volt >meter. However, he also said to look at what it said in the BIOS. I >checked there, and the voltages reported were all fine -- very close >to spec. 5v was 4.94 and so on. He said the 520 was plenty of power >for what I had in my system. They would do the RMA if I wanted but he >really didn't think that was the problem. Agreed, that PSU is more than enough for the system as described. It is not reliable to take a 3rd party software application and assume it is even reading the right *things* to determine voltage level, only after comparison to a multimeter reading (keeping in mind the software tends to report lower than actual values unless there is an artificial offset used and then the actual reading may be closer to correct but the margin for error actually increases in some cases), OR if others have already determined whether the specific software correctly works with the board, then one has found a software suitable for later monitoring purposes. However, that a model of PSU should be enough doesn't rule out that the particular specimen could be faulty but based on what you wrote below it seems not to be the problem or at least not clearly so. >
>He also suggested running memtest. It turns out that I also have >Corsair memory, and I did that. I had run memtest overnight (fine) >when I last upgraded the memory a year or so ago. So, I ran it just >now and got failures (multiple failures at same address). The remaining question is do those addresses ALWAYS fail in every kind of test (every memtest test #). If they always fail it indicates bad addresses, but if not it tends to implicate general memory subsystem instability which is not necessarily damning of the memory because when you installed the faster processor it most likely used a faster FSB & memory bus than the Celeron did. One potential resolution to this is trying a different board bios to increase memory compatiblity. Another is to try manually setting the memory speed and timings to more conservative values. Sometimes memory is ok, that it meets JEDEC specs per it's rating, but after the windows of opportunity for returning it to the seller is gone the manual timings option would be needed, and if you RMA and receive same memory again it could similarly have the problem if it were the board that was to blame. >I pulled
>out one module (the 512) and ran it again (with the remaining 1 gig >module) and found no errors with about 8 minutes of testing. So, I >got an RMA on that memory module, and was expecting that it would have >solved the prob. Not quite. If you pull one and then no errors, it doesn't implicate the other yet. Next you should have put the other module in and pulled out the one currently installed to see if errors remain. Even then, if the board is to blame it can be that having only one or the other modules installed would be ok but having two modules causes errors. There are a few other tweaks that can sometimes improve memory stability including raising memory voltage in bios, raising MCH voltage (either of these should only be raised a small amount if any), and relaxing the memory timings a bit. Reducing the memory bus speed should be the last resort especially if it had to be a ratio change resulting in a large reduction in bus speed because then you aren't quite getting the performance you paid for. >
>The system seemed to run better without the offending 512 module, and >I was able to load it up with quite a few programs running at once, >but I was eventually able to make it fail. The tech support guy also >suggested running orthos in safe mode to stress the system. That ran >for about 10 minutes before the system failed. So, it's running >better, but not totally reliably. Orthos will fail from CPU instability, including CPU overheat, OR from memory and/or northbridge instability. Before booting windows you should run memtest86+ for many hours, like overnight, and only if that has zero errors then proceed to boot windows and run other tests. Personally I like to ensure some margin, to manually set the memory speed (or FSB speed when a ratio) to a few percent, perhaps 5%, higher speed for the test, as this will tend to help find borderline stability issues and I do want any system to have some margin for stability not just barely stable as systems do tend to degrade slightly over time and sometimes memtest86+ will not catch errors if a system were barely instable rather than grossly so. By increasing memory speed (keeping timings set to manual but not changing them yet, keeping set to manual just helps to ensure the bios didn't apply different timings when you increased the bus speed) you tend to find more errors that would otherwise be unfound. Granted, you could even introduce errors that wouldn't have occurred when raising the bus speed but IMO any system should have that 5% or so margin in how it's running and of course you would return the system to stock speed after the memtest86+ test passed with no errors. >
>I'll run memtest overnight on the 1 gig module. I'm open to >suggestions, but leaning toward using it for now (without stressing it >too much), and then replacing it (mobo/mem/cpu) soon. Inspect the motherboard for failing capacitors, particularly the large ones around the CPU socket. Vented or domed tops or leaky residue around top or bottom are common indicators. Try manually lowering the FSB speed to what it was when the Celeron was running, only temporarily as a test. Next run the Memtest86+ overnight and Orthos. I would not "lean towards using it for now" if you have any errors at all, assuming you have the Celeron still it can be reinstalled so you have a stable system until you get a chance to resolve this in your free time - but I can't know how important or unimportant your time or the stability is, different people have different needs per system. It is just troubling to think that you could corrupt data in your windows installation while running a combo that isn't quite stable. Especially, do not defrag the hard drive until you are certain, after a period of time, that the system is fully stable, because if you did corrupt files including windows OS files it becomes much more of a PITA to find the root cause of the error with multiple things going wrong. You did not mention your CPU temperature. If the heatsink isn't mounted good or the case has poor ventilation these can cause errors, particularly after having ran for awhile to heat up but it doesn't take long for CPU to heat up running Orthos, or if it had been running for awhile before starting the Memtest86+ testing. You haven't mentioned what settings your board bios supports, but check on a bios update regarding memory compatiblity and if there is one put the Celeron back in, confirm stability through testing, then flash the newer bios. If there is no newer bios then if the current bios supports reducing memory bus speed that is what I would try first, remembering that it doesn't necessarily indicate faulty memory unless always the same memtest86+ addresses are in error. You could be one of the rare people who simultaneously has more than one problem, possibly a combination of memory instability and CPU overheating, had you ever previously ran Orthos to see how much your temps rose? I mean prior to installing the new CPU? | ||||||||||||||||
|
Posted by on March 15, 2008, 7:28 pm
Please log in for more thread options >
Okay, case closed. All is well and my system appears to be crash-
> You could be one of the rare people who simultaneously has > more than one problem, possibly a combination of memory > instability and CPU overheating, had you ever previously ran > Orthos to see how much your temps rose? =A0I mean prior to > installing the new CPU? > proof. Thanks to all for ideas. Kony, your hunches were close, mainly about memory timings. It looks like there are no hardware problems at all. I conclude that there were some memory timing issues that only surfaced with the faster processor installed. Even with slower memory timings I have now set, the overall performance is still much greater than the Celeron -- most things seem twice as fast. Benchmarks seem to be on par with other dual core systems. After *much screwing around* this was resolved by loosening memory timings. Here are timings that worked: cas 2.5 -> increased to 3.0
Tras 7T increased to 8T
Trp 4T -> increased to 5T Trcd 4T increased to 5T Slowing the memory from 400 to 333 did not help. I wound up putting it back to DDR400. There never was any heat problem. As I mentioned, I have a big Zalman heatsink/fan. Orthos cannot crash the system running in safe mode by itself, or running as one of many programs in a normal Windows session. Linux is running fine, too. Memtest is running without errors. Thanks, Alan. | ||||||||||||||||
| Similar Threads | Posted |
| P5V800 stability with Pentium D 920 | March 14, 2008, 3:09 pm |
| OMG please help - system stability | May 4, 2006, 10:37 pm |
| Re: OMG please help - system stability | May 4, 2006, 10:37 pm |
| p5v800 vs asrock 775 dual 880 | May 11, 2006, 10:31 pm |
| Pentium 4: What is "loadline A" ??? | June 30, 2005, 9:06 am |
| Pentium 4 SL7E4 | October 19, 2007, 4:33 am |
| Pentium Pro mainboard not working, please help! | June 4, 2005, 1:54 pm |
| Pentium 3 Current consumption | April 27, 2006, 8:51 am |
| What does that ATX_12V plug do on a Pentium IV? | September 17, 2007, 4:56 am |
| Pentium 4 540 and Pentioum 4 540J difference(s) | April 11, 2005, 1:27 am |
| Pwr supply for both Pentium 4 and Core 2 Extreme | December 11, 2006, 5:11 pm |
| Need Best Bang for the Buck CPU supporting the Socket 478 Pentium 4 | March 4, 2006, 9:45 am |
| FS Acer TravelMate 1.73GHz Pentium M 512MB/80GB DVD/CD-RW Tablet PC Notebook AND MORE | July 4, 2006, 6:25 am |
> The PC's been running okay with a Celeron D 2.8, although I've never
> been thrilled with the performance. I just got a used dual core
> Pentium D 920 cheap on eBay and installed it. As expected, it works a
> lot faster. I like it. However, it will do a spontaneous reboot if
> stressed. Unacceptable. This is not an Xp problem because it will do
> the same thing in Linux -- load up a few resource-hungry applications
> and start doing things and it will fail. Both cores are working and
> show activity under Linux and Xp. Good, big Zalman CPU heat sink/fan
> -- heat doesn't seem to be a prob.