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

[Ixnei]

For all the ASUS P2B and 440BX slot1 experts out there, TSIA for the most
part.

The board is flashed to 1014.003, The system used with a bare minimum of
processor, memory and video card.

Initially, using a P2-350, 4MB ATI Rage AGP, and 64MB PC100, the system
passes memtest completely.

If, however, I swap out that processor for a Celeron 600/66, 900/100, or
1300/100 (all in slotkets), the system reboots as soon as it is about 1%
into test #6 (It passes all tests #1-5). I have tried 3 different 64MB
SIMM sticks, one at a time, in different DIMM slots with the same
reset/reboot results. (No USB devices, legacy?!...)

I have tried a different video card, and populating the motherboard
completely with ISA sound, PCI 10/100, PCI aha-2940uw, and AGP GF3 ti200
256MB ram, same reboot. I know power supply and all other components
beside motherboard are OK, as I can swap out the P2B with an MS6119 and
all works fine (Tually 1300/100, 256MB @ fastest memory timings).

The capacitors look fine on the board - hell, they look just about brand
new (though this means nothing, I know - but I've seen a lot of blown caps
lately on recycled materials)...

All stock voltages used for the processors, and look fine in hardware
monitor (1.5V for Tualatin, 1.7V for Coppermines). I can boot P2B/tually
1300 into win2k, but haven't messed around much with stability testing
using quake/cpuburn/etc...


Oh, I got a second one of these boards (same revision), which appears to
have the "bad hardware monitor" syndrome - all voltages are measured at 0
and temperatures are pegged at 130C (even with no CPU thermistor
attached), but fan readings appear to work (CPU fan at 5300rpm). Board
looks clean, no visual clues. Tried reflashing it with the 1014nh.003 (no
hardware monitor) bios, but it still detects the CPU overheating (even
though the bios is not supposed to have a hardware monitor anymore), and
throttles the processor down about 25%... So, I get the long continuous
beep and flashing power light when this throttle down occurs.

Any ideas here? I've done plenty of power cycling, resetting/disabling
bios settings and unplugging of AC power/motherboard CMOS battery. It
almost seems like there might be a DMI/ESCD conflict/issue, or an ISA
irq/address confict somehow (only using AGP Rage). It sure seems odd that
even when using a no hardware monitor bios, it detects overheating CPU and
throttles the processor down...

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

 

[Fishface]

It might be related to this:
http://members.ams.chello.nl/mgherard/html/photoshop.html

I had a similar problem on an Abit BF-6 when used with a
Tualatin Celeron 1.1A with a modified MSI slot adapter that
was solved with a similar modification to the slocket.

 

[Roland Scheidegger]

For all the ASUS P2B and 440BX slot1 experts out there, TSIA for the
most part.

The board is flashed to 1014.003, The system used with a bare minimum
of processor, memory and video card.

Initially, using a P2-350, 4MB ATI Rage AGP, and 64MB PC100, the
system passes memtest completely.

If, however, I swap out that processor for a Celeron 600/66, 900/100,
or 1300/100 (all in slotkets), the system reboots as soon as it is
about 1% into test #6 (It passes all tests #1-5). I have tried 3
different 64MB SIMM sticks, one at a time, in different DIMM slots
with the same reset/reboot results. (No USB devices, legacy?!...)

I have tried a different video card, and populating the motherboard
completely with ISA sound, PCI 10/100, PCI aha-2940uw, and AGP GF3
ti200 256MB ram, same reboot. I know power supply and all other
components beside motherboard are OK, as I can swap out the P2B with
an MS6119 and all works fine (Tually 1300/100, 256MB @ fastest
memory timings).

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?

The capacitors look fine on the board - hell, they look just about
brand new (though this means nothing, I know - but I've seen a lot of
blown caps lately on recycled materials)...

That board is from a time when asus didn't put any junk they could find
on their boards ;-).

Oh, I got a second one of these boards (same revision), which appears
to have the "bad hardware monitor" syndrome - all voltages are
measured at 0 and temperatures are pegged at 130C (even with no CPU
thermistor attached), but fan readings appear to work (CPU fan at
5300rpm). Board looks clean, no visual clues. Tried reflashing it
with the 1014nh.003 (no hardware monitor) bios, but it still detects
the CPU overheating (even though the bios is not supposed to have a
hardware monitor anymore), and throttles the processor down about
25%... So, I get the long continuous beep and flashing power light
when this throttle down occurs.

Are you sure you get throttling? Since the cpu can't do it, this would
mean the board has to downclock fsb - I don't think the p2b bios will do
that, at least I've never heard that it can do this. No idea how to fix
the problem, I'd have supposed that the bios without hardware monitoring
would have been enough.
btw does memtest86 test #6 crash with that board too?

Roland

 

[Ixnei]

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?

Curious, Fishface's had a similar response about a mod to Vtt using caps,
to fix an apparent photoshop bug. Do you get that photoshop bug?

http://members.ams.chello.nl/mgherard/html/photoshop.html

I'm using some generic 370SPC slocket, and I will be looking at getting
some tantalum caps soon (if I don't have any appropriate ones already).

That board is from a time when asus didn't put any junk they could find
on their boards ;-).

It's just manufacturing - the clean tanks get gunked up, and have to be
refilled/refreshed/etc every so often. Thin residual layers are going to
be deposited on the "foil" if there is any amount of contaminant in the
clean tanks (which there is always going to be). I've seen blown caps on
socket 7 boards. Yes, it's a quality measure of the capacitor vendor, but
stuff happens too, and there's a spectrum of dirtyness to the cleans...

Are you sure you get throttling? Since the cpu can't do it, this would
mean the board has to downclock fsb - I don't think the p2b bios will do
that, at least I've never heard that it can do this. No idea how to fix
the problem, I'd have supposed that the bios without hardware monitoring
would have been enough.
btw does memtest86 test #6 crash with that board too?

I know it's throttled, the memory bandwidth drops to about 65MB/s from the
~250MB/s that it should be, as reported by memtest, and testing takes
about 4 times longer. It is something the motherboard performs, and is
evidenced by the non-stop beep and slow flashing power light (as opposed
to power light being solid on with a single short beep).

It did pass memtest with the P2-350, but I didn't bother doing further
testing with faster processors as I already ran into a fairly substantial
roadblock with that board.

I've tried google searches on this - found some people with the same
problem, others with some explanations of the phenomena, but never found a
follow up with a solution...

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

 

[Ixnei]

It might be related to this:
http://members.ams.chello.nl/mgherard/html/photoshop.html

I had a similar problem on an Abit BF-6 when used with a Tualatin
Celeron 1.1A with a modified MSI slot adapter that was solved with a
similar modification to the slocket.

Sounds like it could be the same thing - how many caps did you use, and
how did you modify your slotket (did it have a Vtt plane?)? For the cap,
did you make the positive lead as short as possible to a Vtt pin, and the
other lead whatever length needed to get to a ground?

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

 

[Paul]

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

 

[Fishface]

Sounds like it could be the same thing - how many caps did you use, and
how did you modify your slotket (did it have a Vtt plane?)? For the cap,
did you make the positive lead as short as possible to a Vtt pin, and the
other lead whatever length needed to get to a ground?

I did it exactly as the picture on that first page shows, connecting the pins
on the back side of the slocket. I don't remember if there was a large
copper area on the back of the socket. There was a space for another
22uf electrolytic capacitor on the front of the board between Vtt and
ground, so I stuck one in there for good measure.

 

[Fishface]

I did it exactly as the picture on that first page shows, connecting
the pins on the back side of the slocket.

Actually, I think I only used one of the 100nF caps...

 

[P2B]

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.

P2B

 

[Roland Scheidegger]

Curious, Fishface's had a similar response about a mod to Vtt using
caps, to fix an apparent photoshop bug. Do you get that photoshop
bug?

http://members.ams.chello.nl/mgherard/html/photoshop.html

Unfortunately I don't have photoshop, so I couldn't test this.

I'm using some generic 370SPC slocket, and I will be looking at
getting some tantalum caps soon (if I don't have any appropriate ones
already).

Just as a side note, using generic slockets with coppermines (and even
more so modded with tualatins) seems often to be problematic. I'd have
just tried a slot-t, but it's not available in switzerland, and I'm not
willing to pay more than the adapter costs in shipping costs (and the
soltek slotket isn't quite generic, it is listed by intel as meeting
coppermine requirements). If your 370SPC is revision 1.0 from Fastfame
then it's explicitly listed by intel as not coppermine compliant.

I know it's throttled, the memory bandwidth drops to about 65MB/s
from the ~250MB/s that it should be, as reported by memtest, and
testing takes about 4 times longer. It is something the motherboard
performs, and is evidenced by the non-stop beep and slow flashing
power light (as opposed to power light being solid on with a single
short beep).

ah ok. Didn't know it actually throttles and not just flash and blink ;-).

It did pass memtest with the P2-350, but I didn't bother doing
further testing with faster processors as I already ran into a fairly
substantial roadblock with that board.

I've tried google searches on this - found some people with the same
problem, others with some explanations of the phenomena, but never
found a follow up with a solution...

Maybe the monitoring chip is defective? I don't know if that is
probable, but if this is indeed the case you might need to replace it
(I'm not sure if there are other differences between boards with/without
monitoring, but it might work if the chip is removed without replacing it).

Roland

 

[Roland Scheidegger]

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 don't feel good about measuring voltages on boards when it's running
though (even more so if the measurement points are tiny pins), I guess
it's even impossible in that cramped case. I think I'll try modifying
the slocket first.

Roland

 

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

P2B

I'm referring to the behavior if the 6019 detects a fault _after_
a successful boot. While some voltage regulators automatically
recover from a fault, the datasheet for the 6019 looks like you
might need to reset it to restore operation. (Other switchers
run in hiccup mode until the fault is removed.)

Paul

 

[Ixnei]

Unfortunately I don't have photoshop, so I couldn't test this.


Just as a side note, using generic slockets with coppermines (and even
more so modded with tualatins) seems often to be problematic. I'd have
just tried a slot-t, but it's not available in switzerland, and I'm not
willing to pay more than the adapter costs in shipping costs (and the
soltek slotket isn't quite generic, it is listed by intel as meeting
coppermine requirements). If your 370SPC is revision 1.0 from Fastfame
then it's explicitly listed by intel as not coppermine compliant.

Yeah, well they work in the other boards I've tested. In fact, this type
of slotket with both a 733 and a 766 celeron worked fine in a P2L97,
and passed memtest. The P2B just doesn't seem to have enough noise
immunity.

Maybe the monitoring chip is defective? I don't know if that is
probable, but if this is indeed the case you might need to replace it
(I'm not sure if there are other differences between boards with/without
monitoring, but it might work if the chip is removed without replacing it).

Yeah that might be a possibility. I know on the other board the CPU temp
shows up as a non-selectable N/A (not 130C [Err]), so perhaps this route
might work. I'd rather just disable the throttling somehow in the bios...

Roland

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

 

[David Maynard]

Unfortunately I don't have photoshop, so I couldn't test this.


Just as a side note, using generic slockets with coppermines (and even
more so modded with tualatins) seems often to be problematic. I'd have
just tried a slot-t, but it's not available in switzerland, and I'm not
willing to pay more than the adapter costs in shipping costs (and the
soltek slotket isn't quite generic, it is listed by intel as meeting
coppermine requirements). 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.


<snip>

 

[P2B]

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.

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.

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.

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 don't feel good about measuring voltages on boards when it's running
though (even more so if the measurement points are tiny pins), I guess
it's even impossible in that cramped case. I think I'll try modifying
the slocket first.

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.

P2B

 

[P2B]

I'm referring to the behavior if the 6019 detects a fault _after_
a successful boot. While some voltage regulators automatically
recover from a fault, the datasheet for the 6019 looks like you
might need to reset it to restore operation. (Other switchers
run in hiccup mode until the fault is removed.)

Paul

It turns out nothing happens as a direct result of the 6019 detecting a
fault at _any_ time as there is no connection to the fault pin - see my
other post in this thread.

 

[David Maynard]

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.

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

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>

 

[Paul]

It turns out nothing happens as a direct result of the 6019 detecting a
fault at _any_ time as there is no connection to the fault pin - see my
other post in this thread.

But doesn't the 6019 shut down anyway ? My point is, the processor loses
power (because the 6019 latched a fault), but the ATX PS is still
powered. What the fans do, depends on where the logic signals that
control the power transistor on the fan header, come from. This is
not a normal way for the board to run - on a multiple supply board,
you would want it to shut down, rather than bias being applied to
some supplies and not others.

On the 6019, the fault signal isn't connected, because the PGOOD
signal is used. You probably already have a copy of this reference
schematic, and if you search for PWRGOOD and look at some of the
logic, the equivalent of PGOOD from a VRM is used as part of the
logic for PWROK which is fed to a couple of major chips on the
board.

ftp://download.intel.com/design/chipsets/designex/BXDPDG10.PDF

I notice on that reference schematic, how VTT has a 22uF cap on
it for filtering. Maybe that is where the workaround value
came from ?

Paul

 

[Ixnei]

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.

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=p...TF-8&[email protected]&rnum=5

I will try playing with disabling "green" power functionality in the BIOS.

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.

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

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

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.

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.

If the voltage regulator shuts down due to an error, I assume weird
things might happen - including a half shutdown immediately followed by
a restart (which could explain the fans spinning slower).

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

Roland