Asus P2B v1.10 reboots @beginning of test #6 in memtest

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"...

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 ##

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

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

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!!!

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.

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"...

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

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"...

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