If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#21
|
|||
|
|||
On Fri, 23 Apr 2004 14:35:01 +0200, Roland Scheidegger wrote:
P2B wrote: I find this whole thread rather odd, as it's replete with reports of P2B behaviors which don't match my experience with the boards at all! I've decided to consolidate my thoughts and observations here rather than in a series of replies to other posts in the thread. You probably don't use substandard slockets ;-). And even if you do, if it's indeed caused by improper vtt buffering, then it's exactly the sort of issue you'd expect to only see on some boards, not on all, even if it's the same revision. I believe he also does mods to Vtt on the motherboard in order to drop Vtt voltages, which should also reduce Vtt noise to some extent... http://tipperlinne.com/p2b-dsvtt.htm And finally, back to the original issue of memtest86 crashing shortly after starting test 6. I've never seen this under any circumstances. Are we talking about the original memtest86 v3.0 (which I've used on P2B boards for years), or memtest86 3.1a, or memtest86+ 1.x ?? I've never used any of the recently released versions. I've tried with memtest86 3.0, and memtest86+ 1.11 (I've switched to that so I could compile it myself, since 3.0 needs an ancient gcc 2.95.3). I wasn't aware that there's now a memtest86 3.1 version, the 3.0 version was there for a LONG time. I don't think though testing with 3.1 would change the result... (I also forgot to mention the problem is independant of vcore (tested 1.4/1.5/1.6V) or fsb/cpu clock (tested 133, 100 and 66MHz FSB)). I've also used 3.0 and 1.11 - same results on both (system reboot about 1-2% into test #6). -- We HAVE been at war with Iraq for 13 years now, bombing their country on at least a weekly basis. "U.S.-led sanctions have killed over a million Iraqi citizens, according to UN studies" - James Jennings 3,000+ innocent Iraqi civilian casualties can't be "wrong"... |
#22
|
|||
|
|||
On Thu, 22 Apr 2004 19:04:27 -0500, David Maynard
wrote: If your 370SPC is revision 1.0 from Fastfame then it's explicitly listed by intel as not coppermine compliant. Yes, it's on the "DO NOT Meet Minimum Requirements" list but I'm not quite sure what to make of that list as they also have the Super Slocket III, which is about the only slotket still available, on it but they do work. At least the two I have did. IMHO slotkets there on that list (I have it too) are there because not compatible TL for SMP operations & IMHO when not used in dual CPU configurations, they anyway should work w/o problem (also some with Tuallie like the one you mention (& its the same mine I run Tuallie on it...) -- Regards, SPAJKY ® & visit my site @ http://www.spajky.vze.com "Tualatin OC-ed / BX-Slot1 / inaudible setup!" E-mail AntiSpam: remove ## |
#23
|
|||
|
|||
Roland Scheidegger wrote:
I've tried with memtest86 3.0, and memtest86+ 1.11 (I've switched to that so I could compile it myself, since 3.0 needs an ancient gcc 2.95.3). I wasn't aware that there's now a memtest86 3.1 version, the 3.0 version was there for a LONG time. I don't think though testing with 3.1 would change the result... (I also forgot to mention the problem is independant of vcore (tested 1.4/1.5/1.6V) or fsb/cpu clock (tested 133, 100 and 66MHz FSB)). Ok, some update to this. I've soldered some caps to the back of the slotket, pretty much following this guide here (http://members.chello.nl/mgherard/html/photoshop.html) except of course I've soldered the third capacitor to a different location. But: no chage at all :-(. It still reboots at 2% in memtest test #6. I've exchanged the cpu back to the celeron 850 (actually it's a 566...) and it no longer crashes. Also, some more information on the memtest86 test #6 crashes. In about 3 of 4 cases, it reboots, with clearly the cpu fan spinning down for a short period of time. In 1 of 4 cases, it shuts down, psu fan still running, cpu fan no longer running, case power light off, hd light on. Neither the ATX power switch (even when pressed for 10s) nor the reset switch will do anything in that state. I understand your trepidation, but IME errant probing of a running board rarely causes problems a reboot doesn't cure. Tip: The contacts in a female Molex connector fit nicely on most meter probes. To make fine probes for your meter, just remove a couple from a spare Molex, solder jumper pins from a dead board onto them, and slide onto the existing probes. Now you can measure individual chip pins on the board with greatly reduced risk of shorting to an adjacent pin. I'll try it when soldering vtt caps doesn't help. I've measured that rt/fault pin, when the pc works I've measured 1.29V (as it about should be according to the datasheet). When the pc was in that pseudo-shutdown state, the rt/fault pin was measured at 10.8V, which would indeed support paul's assumption that the hip6019bcb has latched an error and shut itself down. I've also measured vtt (on a cpu pin), was 1.51V when running. Any ideas what to do or why the voltage regulator would shut down? I think I'll try soldering vtt voltage to a somewhat lower value next weekend (should get current down a bit), though I'm not that confident that the power regulator shuts down due to an overcurrent on the vtt lane. Roland |
#24
|
|||
|
|||
David Maynard wrote: P2B wrote: Roland Scheidegger wrote: P2B wrote: Actually, I've recently noticed exactly the same behaviour here. memtest test #6 always reboots at 2% (and sometimes it won't even reboot, but some very odd shutdown happens - fans etc. will spin down, power led will go off, but hd led stays lit(!)). I can run all other tests all day long, as well as things like cpuburn. What's very weird about that memtest #6 failure is also that it doesn't matter at all what memory area is tested and how large the memory area is - it will always crash at 2%, no matter what. I wanted to try some things (like soldering additional caps to vtt) since I suspect the slotket I have (soltek sl-02a++, modded to work with tualatin) might not do a good job (it's just a wild guess though), but didn't have time yet. What slotket do you have? Roland Are the symptoms consistent with the HIP6019 latching a fault ? http://www.intersil.com/data/fn/fn4587.pdf Paul No. The board won't power up if the HIP6019 latches a fault - usually the CPU fan will 'twitch' at power up, but the board shuts down again immediately. Hmm. Are you sure this always happens? Looking at the datasheet, it could explain the behaviour I see (the strange shutdowns, and also (I forgot to mention that before) when it reboots, I can hear the fans (I assume cpu fan, but I haven't listened that closely) spinning slower for a very short period of time (which doesn't happen with a normal reset). I find this whole thread rather odd, as it's replete with reports of P2B behaviors which don't match my experience with the boards at all! I've decided to consolidate my thoughts and observations here rather than in a series of replies to other posts in the thread. With regard to VRM fault, I had assumed the HIP6019 fault signal was involved in shutting down the board if there's a problem in the VRM circuitry, but that turns out not to be the case. I just checked through my inventory of parts boards and found several flavours of P2B with the 6019 removed. There is no connection to pin 13 (FAULT/RT) on any of them. To me this implies the hardware monitoring chip (W83781D) is somehow involved, which is consistent with my experience. I once burned out a fan tachometer input on one of my boards and decided to replace the monitor chip. The board would not power on without the monitor chip - I tried it for interest's sake and the symptoms were identical to a failed 6019, i.e. CPU fan twitches but board does not power up. This still doesn't tell us what happens if the chip shuts down during operation, however. As an aside, failure of the W83781D chip can be very frustrating if you are trying to repair a dead board. To date I have been unable to find a way to diagnose W83781D vs. 440BX Northbridge failure. I have fixed two P2B-DS boards by replacing the W83781D 'on spec', but three others were still dead afterward. Your report of fans spinning slower on reboot after a 'strange shutdown' does not seem plausible as there is nothing but a power transistor between +12v from the power supply and the onboard fan headers. I assume the power transistor is there to be sacrificed if a fan header supply pin is shorted to ground, otherwise traces on the board might melt. I've fixed a couple of boards with dead fan headers by replacing this transistor, and in both cases it failed after a chassis fan seized. I suppose it would be possible to slow the fans by pulsing the 'on' signal to the power transistor, but this seems unlikely to me. My P2B has practically nothing in the way of monitoring but your supposition about pulsing the 'on' signal to the transistor is precisely how SpeedFan works on my BP6. If the fan can be turned off for, say, suspend then it can be pulsed too. True - however I've never seen a P2B run the fans slow, but that could be because I've never triggered the BIOS to do so - which seems unlikely given the amount of testing and repair I've done one these boards. The OP's report of 'CPU throttling' also appears implausible since the BIOS does not appear to have such functionality. This is expected since CPUs available when the board was designed did not support throttling, nor does the BIOS contain the I2C code required to instruct the clock chip to change FSB on the fly. Note that the OP's temperature readings are easily simulated - 130 degrees is the maximum the monitoring chip can report, and is obtained by connecting the sensor input pins together. I tried that on several flavours of P2B here, and in all cases the BIOS reports a hardware error, but boots normally if you hit F2 - with fans and FSB both running at their usual speeds. My P2B (VM) doesn't have any visible CPU throttling function in BIOS either and while your comment about CPUs of the era not 'supporting' it is true that doesn't mean CPU throttling couldn't be, and wasn't, done. My original issue BH6, for example, has BIOS settings for CPU throttling: 75%, 62.5%, 50%, etc. There was no 'CPU support' needed as those older systems throttled by blocking the system clock. It's processor independent. Now, I also note that my P2B runs ACPI and if his thermal sensor is 'broke' at 130 I wonder if windows itself could be throttling, which would depend on the ACPI table (thermal zones). Have you looked to see what the P2B BIOS has in there? I didn't boot Windows when I tested this the other day, so I just fired up a P2B-DS with both CPU temperature sensors shorted, i.e. jammed at 130 degrees. The BIOS complains it found a hardware error, then emits a constant tone from the speaker after you tell it to boot anyway. Windows XP Pro then boots normally, and according to Sandra, is not throttling. CPU and FSB speeds are reported to be normal, and benchmark results are also normal. I suppose it could also be possible that the BIOS has a non adjustable throttle built in at some fixed temperature value and, as noted above, it wouldn't need to set an FSB freq into the clock gen to do it. Possibly, but I can't seem to trigger it! Given the above, my best guess is the symptoms observed by the OP on the board with the funky hardware monitor are entirely due to the monitoring chip failing in an unusual fashion, resulting in the BIOS becoming thoroughly confused when it reads (or tries to read) the monitor chip's registers. snip |
#25
|
|||
|
|||
Ixnei wrote: On Thu, 22 Apr 2004 22:48:31 -0400, P2B wrote: I find this whole thread rather odd, as it's replete with reports of P2B behaviors which don't match my experience with the boards at all! I've decided to consolidate my thoughts and observations here rather than in a series of replies to other posts in the thread. snip The OP's report of 'CPU throttling' also appears implausible since the BIOS does not appear to have such functionality. This is expected since CPUs available when the board was designed did not support throttling, nor does the BIOS contain the I2C code required to instruct the clock chip to change FSB on the fly. Note that the OP's temperature readings are easily simulated - 130 degrees is the maximum the monitoring chip can report, and is obtained by connecting the sensor input pins together. I tried that on several flavours of P2B here, and in all cases the BIOS reports a hardware error, but boots normally if you hit F2 - with fans and FSB both running at their usual speeds. Evidently standby mode is entered 75% of the time in a short timecycle: http://groups.google.com/groups?q=p2...eds.com&rnum=5 I will try playing with disabling "green" power functionality in the BIOS. I can't find any evidence the information in that post is correct. I currently have a P2B-DS running on the bench with both CPU sensors shorted and reporting 130 degrees, and Sandra benchmarks running. The onboard speaker is emitting a constant tone, but apart from that I'm getting normal benchmark values and Task Manager is reporting 100% CPU utilisation while the benchmark is running. Given the above, my best guess is the symptoms observed by the OP on the board with the funky hardware monitor are entirely due to the monitoring chip failing in an unusual fashion, resulting in the BIOS becoming thoroughly confused when it reads (or tries to read) the monitor chip's registers. Even when using the "no hardware monitor" BIOS? I think you're correct tho, that it is still reading them and believing there is a heat problem. The board I was working on wouldn't even power on without a hardware monitor chip, so there must be some dependency on the chip regardless of which BIOS is installed. And finally, back to the original issue of memtest86 crashing shortly after starting test 6. I've never seen this under any circumstances. Are we talking about the original memtest86 v3.0 (which I've used on P2B boards for years), or memtest86 3.1a, or memtest86+ 1.x ?? I've never used any of the recently released versions. I'm using the most recently released version - I have the older 3.0 version which I will shortly test to confirm/deny this!!! |
#26
|
|||
|
|||
Roland Scheidegger wrote:
Roland Scheidegger wrote: I've tried with memtest86 3.0, and memtest86+ 1.11 (I've switched to that so I could compile it myself, since 3.0 needs an ancient gcc 2.95.3). I wasn't aware that there's now a memtest86 3.1 version, the 3.0 version was there for a LONG time. I don't think though testing with 3.1 would change the result... (I also forgot to mention the problem is independant of vcore (tested 1.4/1.5/1.6V) or fsb/cpu clock (tested 133, 100 and 66MHz FSB)). Ok, some update to this. I've soldered some caps to the back of the slotket, pretty much following this guide here (http://members.chello.nl/mgherard/html/photoshop.html) except of course I've soldered the third capacitor to a different location. But: no chage at all :-(. It still reboots at 2% in memtest test #6. I've exchanged the cpu back to the celeron 850 (actually it's a 566...) and it no longer crashes. Also, some more information on the memtest86 test #6 crashes. In about 3 of 4 cases, it reboots, with clearly the cpu fan spinning down for a short period of time. In 1 of 4 cases, it shuts down, psu fan still running, cpu fan no longer running, case power light off, hd light on. Neither the ATX power switch (even when pressed for 10s) nor the reset switch will do anything in that state. I understand your trepidation, but IME errant probing of a running board rarely causes problems a reboot doesn't cure. Tip: The contacts in a female Molex connector fit nicely on most meter probes. To make fine probes for your meter, just remove a couple from a spare Molex, solder jumper pins from a dead board onto them, and slide onto the existing probes. Now you can measure individual chip pins on the board with greatly reduced risk of shorting to an adjacent pin. I'll try it when soldering vtt caps doesn't help. I've measured that rt/fault pin, when the pc works I've measured 1.29V (as it about should be according to the datasheet). When the pc was in that pseudo-shutdown state, the rt/fault pin was measured at 10.8V, which would indeed support paul's assumption that the hip6019bcb has latched an error and shut itself down. I've also measured vtt (on a cpu pin), was 1.51V when running. Any ideas what to do or why the voltage regulator would shut down? I think I'll try soldering vtt voltage to a somewhat lower value next weekend (should get current down a bit), though I'm not that confident that the power regulator shuts down due to an overcurrent on the vtt lane. Roland The symptom you describe is consistent with a motherboard over current, with the PSU unaffected. They're typically fold back current limiters which won't get reset till power is removed. And since the power switch circuitry is in the affected electronics it doesn't work either. |
#27
|
|||
|
|||
On Sun, 25 Apr 2004 20:54:32 -0400, P2B wrote:
Ixnei wrote: snip Evidently standby mode is entered 75% of the time in a short timecycle: http://groups.google.com/groups?q=p2...eds.com&rnum=5 I will try playing with disabling "green" power functionality in the BIOS. I can't find any evidence the information in that post is correct. I currently have a P2B-DS running on the bench with both CPU sensors shorted and reporting 130 degrees, and Sandra benchmarks running. The onboard speaker is emitting a constant tone, but apart from that I'm getting normal benchmark values and Task Manager is reporting 100% CPU utilisation while the benchmark is running. It is true for the P2B v1.10 that I have - the P2B-DS bios must be different enough that you do not see this throttling. Memtest reports the memory bus bandwidth at ~60MB/s when it should be more like 240MB/s, and the testing took 4 times longer than normal on a 64MB PC100 DIMM. There are also plenty of posts about people who are having problems with their P2B systems running terribly slow when the CPU temperature is maxed (caused by short of thermistor pins). Hmm, maybe I can flash my P2B board with the P2B-D bios (which may not have the "feature" the P2B-DS bios seems to have) - I doubt it?!... Certainly the bios would need to be coded differently for this particular aspect, as there are two different thermistor signals which both need to be looked at on the D boards. snip I'm using the most recently released version - I have the older 3.0 version which I will shortly test to confirm/deny this!!! Same test #6 2% reboot results obtained using older v3.0, as expected. -- We HAVE been at war with Iraq for 13 years now, bombing their country on at least a weekly basis. "U.S.-led sanctions have killed over a million Iraqi citizens, according to UN studies" - James Jennings 3,000+ innocent Iraqi civilian casualties can't be "wrong"... |
#28
|
|||
|
|||
Roland Scheidegger wrote: Roland Scheidegger wrote: I've tried with memtest86 3.0, and memtest86+ 1.11 (I've switched to that so I could compile it myself, since 3.0 needs an ancient gcc 2.95.3). I wasn't aware that there's now a memtest86 3.1 version, the 3.0 version was there for a LONG time. I don't think though testing with 3.1 would change the result... (I also forgot to mention the problem is independant of vcore (tested 1.4/1.5/1.6V) or fsb/cpu clock (tested 133, 100 and 66MHz FSB)). Ok, some update to this. I've soldered some caps to the back of the slotket, pretty much following this guide here (http://members.chello.nl/mgherard/html/photoshop.html) except of course I've soldered the third capacitor to a different location. But: no chage at all :-(. It still reboots at 2% in memtest test #6. I've exchanged the cpu back to the celeron 850 (actually it's a 566...) and it no longer crashes. Also, some more information on the memtest86 test #6 crashes. In about 3 of 4 cases, it reboots, with clearly the cpu fan spinning down for a short period of time. In 1 of 4 cases, it shuts down, psu fan still running, cpu fan no longer running, case power light off, hd light on. Neither the ATX power switch (even when pressed for 10s) nor the reset switch will do anything in that state. I understand your trepidation, but IME errant probing of a running board rarely causes problems a reboot doesn't cure. Tip: The contacts in a female Molex connector fit nicely on most meter probes. To make fine probes for your meter, just remove a couple from a spare Molex, solder jumper pins from a dead board onto them, and slide onto the existing probes. Now you can measure individual chip pins on the board with greatly reduced risk of shorting to an adjacent pin. I'll try it when soldering vtt caps doesn't help. I've measured that rt/fault pin, when the pc works I've measured 1.29V (as it about should be according to the datasheet). When the pc was in that pseudo-shutdown state, the rt/fault pin was measured at 10.8V, which would indeed support paul's assumption that the hip6019bcb has latched an error and shut itself down. I've also measured vtt (on a cpu pin), was 1.51V when running. Very interesting. Same measurements here while running, and no change when XP goes into standby mode - so ACPI definitely does not shut down the 6019 (as expected since the datasheet says power-on reset is required to reset it). The 6019 latching a fault explains why the power and reset switches have no effect. Any ideas what to do or why the voltage regulator would shut down? I think I'll try soldering vtt voltage to a somewhat lower value next weekend (should get current down a bit), though I'm not that confident that the power regulator shuts down due to an overcurrent on the vtt lane. The datasheet says it shuts down if it detects 15% overvoltage on Vcore, and also monitors all output voltages and MOSFET on-resistances to detect and protect against overcurrent - but I'm mystified as to how memtest86 could trigger any of these conditions, and I'm unable to reproduce this behavior - which continues to suggest the slot adapter may be involved. Do the slot adapters in question have TVC16222 (or equivalent) voltage clamp chips? If not, perhaps the fault is triggered by overcurrent on the Vcmos rail. The 6019 generates 2.5V (correct for slot 1 processors), which is clamped to the 1.5V specified for S370 processors on all the slot adapters I have - but I know some adapters do not have the clamps. P2B |
#29
|
|||
|
|||
On Mon, 26 Apr 2004 00:20:04 +0200, Roland Scheidegger wrote:
snip Ok, some update to this. I've soldered some caps to the back of the slotket, pretty much following this guide here (http://members.chello.nl/mgherard/html/photoshop.html) except of course I've soldered the third capacitor to a different location. But: no chage at all :-(. It still reboots at 2% in memtest test #6. I've exchanged the cpu back to the celeron 850 (actually it's a 566...) and it no longer crashes. Interesting, I'm still waiting on a soldering iron tip to get shipped to me before I can proceed (I don't want to hack it with my radio shack butane iron LOL)! I can't get my celeron 600/66 or 900/100 to work, but apparently these would work just fine in your board. Could this be inadequate capacitance or a capacitor wearout mechanism, similar to the blown caps problem? I'm wondering if a "shotgun" (or "selective") replacement of the 1000/1500uF capacitors on the motherboard would help - my board has 22 1000uF 6.3V caps (3 Sanyo SE8N, 19 Rubycon YXG) and one 1500uF 6.3V cap (Sanyo S.E.8N). The Rubycon's seem pretty darned small for 1000uF caps (8x12, as opposed to 8x16+ for YXH series and most other switching caps), and it's not clear to me why the Sanyo caps are used (they are significantly "taller")... FWIW, CE3,18,27 are missing caps, and CE12 is drawn to 1500uF size on board, but using 1000uF. The Sanyo's are CE2,8,10,12. Does this look like what your board is populated with? snip I've measured that rt/fault pin, when the pc works I've measured 1.29V (as it about should be according to the datasheet). When the pc was in that pseudo-shutdown state, the rt/fault pin was measured at 10.8V, which would indeed support paul's assumption that the hip6019bcb has latched an error and shut itself down. I've also measured vtt (on a cpu pin), was 1.51V when running. Any ideas what to do or why the voltage regulator would shut down? I think I'll try soldering vtt voltage to a somewhat lower value next weekend (should get current down a bit), though I'm not that confident that the power regulator shuts down due to an overcurrent on the vtt lane. Sounds like a nice triggerable o-scope might help to indicate which voltage is going out of spec... I unfortunately am also lacking in good dmm/probes/scopes... FYI, I had also tried the VIO setting higher, to no avail... -- We HAVE been at war with Iraq for 13 years now, bombing their country on at least a weekly basis. "U.S.-led sanctions have killed over a million Iraqi citizens, according to UN studies" - James Jennings 3,000+ innocent Iraqi civilian casualties can't be "wrong"... |
#30
|
|||
|
|||
P2B wrote:
Any ideas what to do or why the voltage regulator would shut down? I think I'll try soldering vtt voltage to a somewhat lower value next weekend (should get current down a bit), though I'm not that confident that the power regulator shuts down due to an overcurrent on the vtt lane. The datasheet says it shuts down if it detects 15% overvoltage on Vcore, and also monitors all output voltages and MOSFET on-resistances to detect and protect against overcurrent - but I'm mystified as to how memtest86 could trigger any of these conditions, and I'm unable to reproduce this behavior - which continues to suggest the slot adapter may be involved. Quite possible. I've just googled again on tualatin mods (some overview what's different between ppga, fcpa and fcpga2 can be found here, http://www.rom.by/articles/S370/_english_part3.htm it's a bit hard to read though) as well as looked at the datasheets, and there are still some potential issues left with the mod I've done. In particular, quite a few people connected G35 (Vtt) to G37 (vtt only on tualatin) (which I didn't), X34 looks potentially very problematic, and I might also try toying around with N37 (nchctrl on tualatin) - not before next weekend though. It's just strange it causes an error in the voltage regulator. Do the slot adapters in question have TVC16222 (or equivalent) voltage clamp chips? If not, perhaps the fault is triggered by overcurrent on the Vcmos rail. The 6019 generates 2.5V (correct for slot 1 processors), which is clamped to the 1.5V specified for S370 processors on all the slot adapters I have - but I know some adapters do not have the clamps. My soltek sl-02a++ has two lvc07a. I believe intel requires voltage clamps for all these 2.5V-1.5V pins for an adapter to get approved. But even without the clamps, I doubt it would cause an error in the voltage regulator - current should be pretty minimal, no matter how overvolted. Roland |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Sudden incompatibility between Asus Motherboard p4s3 and Asus v7700 video card | Wil | General | 0 | November 25th 04 11:38 AM |
ASUS K8V Deluxe - Motherboard | Andre | General | 2 | October 13th 04 01:46 AM |
64 benches | Ed Light | AMD x86-64 Processors | 2 | April 4th 04 08:16 PM |