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

[Ixnei]

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

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

 

[Roland Scheidegger]

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

 

[P2B]

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.

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!

 

[P2B]

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.

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.

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.

 

[David Maynard]

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

 

[Ixnei]

Ixnei wrote:


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.


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

 

[P2B]

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

 

[Ixnei]

On Mon, 26 Apr 2004 00:20:04 +0200, Roland Scheidegger wrote:

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?

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

 

[Roland Scheidegger]

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

 

[Roland Scheidegger]

On Mon, 26 Apr 2004 00:20:04 +0200, Roland Scheidegger wrote:




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 doubt that it's due to the vcore caps (the 600/66 is very modest
regarding power draw, you could probably remove half the capacitors and
it would still work fine), but it might be possible the adapter does a
bad job (there likely should be some (small) capacitors on the slotket
to improve HF performance). It could be due to improper buffering on the
vtt lane, again possibly because of the adapter (my adapter has some
100uF and some smaller caps on the vtt plane, not that it helps much...).

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?

From my memory, that sounds about right - I know there were some
unpopulated places. I can take a closer look next weekend. If you want
to add additional capacitors, I'd definitely first start with adding to vtt.

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

I could get access to a digital scope (only 20Mhz sampling frequency or
so though), but I'd rather avoid it (it's fun messing with hardware - up
to a certain point...).

FYI, I had also tried the VIO setting higher, to no avail...

Forgot to mention, but I've also tried that without success.

Roland

 

[Ixnei]

I doubt that it's due to the vcore caps (the 600/66 is very modest
regarding power draw, you could probably remove half the capacitors and
it would still work fine), but it might be possible the adapter does a
bad job (there likely should be some (small) capacitors on the slotket
to improve HF performance). It could be due to improper buffering on the
vtt lane, again possibly because of the adapter (my adapter has some
100uF and some smaller caps on the vtt plane, not that it helps
much...).

I've used this exact same mod on many other slot1 boards, without this
memtest reboot issue. I highly doubt that this P2B has some necessary
overvoltage protection that the other boards are lacking.

Here is a laundry list of boards I've personally tested with this
slotket/1.3 tualatin that loop for hours on memtest, and exhibit no other
instability problems (quake timedemo looping, cpuburn, OS, etc):
Abit BX6v1
Abit BX6v2
Asus P3C2000
MSI MS6119
Micronics Redstone

This reboot thing appears to me to be a peculiarity specific to the P2B
board. Perhaps it is just ever-so-slightly more sensitive, but like I
said, I've tested plenty of other different BX boards (and an i820)
without seeing this.

The mod I use follows:
ak4 to an11 - Vttpwrgd to Vtt
g35 to g37 - Vtt
isolate pins aj3, ak4, an3 - Disable Vss shorts

When I look at all these boards, the one thing that stands out to me is
that all other boards appear to be using bigger, beefier 1000uF 6.3V caps
- it's actually glaringly obvious. It almost seems to me like these
Rubycon caps are labelled wrong, as I can't find any switching caps with
such a small footprint (8x12)...

From my memory, that sounds about right - I know there were some
unpopulated places. I can take a closer look next weekend. If you want
to add additional capacitors, I'd definitely first start with adding to
vtt.

I'd be interested to see if your board uses the same vendor mix/etc.

I could get access to a digital scope (only 20Mhz sampling frequency or
so though), but I'd rather avoid it (it's fun messing with hardware - up
to a certain point...).

I remember about 15 years ago playing with an analog scope that had a
memory of sorts, and could store triggerable event traces. It was always
pretty time consuming getting this sort of "data"...

--
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've used this exact same mod on many other slot1 boards, without
this memtest reboot issue. I highly doubt that this P2B has some
necessary overvoltage protection that the other boards are lacking.

Here is a laundry list of boards I've personally tested with this
slotket/1.3 tualatin that loop for hours on memtest, and exhibit no
other instability problems (quake timedemo looping, cpuburn, OS,
etc): Abit BX6v1 Abit BX6v2 Asus P3C2000 MSI MS6119 Micronics
Redstone

This reboot thing appears to me to be a peculiarity specific to the
P2B board. Perhaps it is just ever-so-slightly more sensitive, but
like I said, I've tested plenty of other different BX boards (and an
i820) without seeing this.

It might not only be p2b specific, but p2b revision 1.10, and maybe not
even all boards (they don't use all the same voltage regulator, maybe
they other parts (like capacitors) aren't the same?)

The mod I use follows: ak4 to an11 - Vttpwrgd to Vtt g35 to g37 - Vtt
isolate pins aj3, ak4, an3 - Disable Vss shorts

When I look at all these boards, the one thing that stands out to me
is that all other boards appear to be using bigger, beefier 1000uF
6.3V caps - it's actually glaringly obvious. It almost seems to me
like these Rubycon caps are labelled wrong, as I can't find any
switching caps with such a small footprint (8x12)...

If the board would really lack capacitors, then certainly that
"photoshop mod" I've performed wouldn't help - that's good for improving
HF perfomance, but the capacitors I've used certainly couldn't
compensate for the lack of capacitance in the order of ~1000uF.
According to the rubycon website, the 8x11.5 YXG 6.3V parts are indeed
only 680uF, 8x16 YXG 6.3V would be 1000uF.

I'd be interested to see if your board uses the same vendor mix/etc.

Ok, I'll take a close look next weekend. It might be interesting to
figure out which ones are for vtt, which ones for vcore, though that
would probably be hard to figure out (measuring at the underside of the
motherboard). I'll assume your second half-dead p2b board has exactly
the same capacitors?
Now I just need to find some 1000uF low-ESR caps - I guess they can
easily be found on dead mobos ;-).

Roland

 

[P2B]

It might not only be p2b specific, but p2b revision 1.10, and maybe not
even all boards (they don't use all the same voltage regulator, maybe
they other parts (like capacitors) aren't the same?)

Might be worth trying it without G35 to G37 - that's how I have my Asus
S370-DLs wired and they don't have this issue.

If the board would really lack capacitors, then certainly that
"photoshop mod" I've performed wouldn't help - that's good for improving
HF perfomance, but the capacitors I've used certainly couldn't
compensate for the lack of capacitance in the order of ~1000uF.
According to the rubycon website, the 8x11.5 YXG 6.3V parts are indeed
only 680uF, 8x16 YXG 6.3V would be 1000uF.

I rummaged through the inventory again looking at the capacitors...
interesting. Rubycon YXG 1000uF 6.3v 105C capacitors apparently come in
at least 3 sizes - 8x12, 8x16, and 8x21

The only vanilla P2Bs I have are rev. 1.02, but both have the capacitor
layout described previously - Rubycon 8x12 plus 3 8x21 Sanyos also
1000uF 6.3v.

The P2B-S/LS boards have a mix of Rubycon 8x12 and 8x21. Newer revisions
appear to use more 8x21.

The dual boards (P2B-D/DS) use a mix of 8x12 and 8x16, and again newer
revisions have more of the taller capacitors. P2B-D/DS 1.06 D03 (the
final revision) uses 8x16 exclusively.

 

[P2B]

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.

The only modded slockets I have are Asus S370DL, which have ak4 - an11
and aj3, ak4, an3 isolated (same as yours, I think, no G35 - G37) and do
not exhibit this problem.

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.

I admit to grasping at straws

 

[Ixnei]

Might be worth trying it without G35 to G37 - that's how I have my Asus
S370-DLs wired and they don't have this issue.

It appears that Roland is not using this one, but having the problem
still:

*****

... In particular, quite a few people connected G35 (Vtt) to G37 (vtt
only on tualatin) (which I didn't), ... *****


I rummaged through the inventory again looking at the capacitors...
interesting. Rubycon YXG 1000uF 6.3v 105C capacitors apparently come in
at least 3 sizes - 8x12, 8x16, and 8x21

I've seen that the larger capacitors for a given uF/V rating have lower
impedance, so perhaps these smaller ones simply have higher impedance
values. Not sure what the consequences of this would be, other than maybe
worse switching response at high frequencies (it's been a while since
my AC daze)...

The only vanilla P2Bs I have are rev. 1.02, but both have the capacitor
layout described previously - Rubycon 8x12 plus 3 8x21 Sanyos also
1000uF 6.3v.

The P2B-S/LS boards have a mix of Rubycon 8x12 and 8x21. Newer revisions
appear to use more 8x21.

The dual boards (P2B-D/DS) use a mix of 8x12 and 8x16, and again newer
revisions have more of the taller capacitors. P2B-D/DS 1.06 D03 (the
final revision) uses 8x16 exclusively.

Interesting trend, there must have been some sort of reason for them to
use 'presumably' more expensive capacitors.

Yes, they both have the same exact capacitor configuration, just the
brands of caps changed. The 3 tall sanyo 1000uF changed to rubycon, and
all the small caps are now "LXZ" (not sure of brand).

http://bertech.com/Components/chemi-con/miniradial/lxz_detail.htm

I personally prefer to use new capacitors, rather than those which have
been approaching the end of their useful lifetime. Most of these
capacitors are rated for lifetimes of 2-3,000 hours, which really isn't
that much "up-time" on a computer. The long-life ones maybe go out to
8,000 hours, which is just short of one year (at 24/7 'on'). I believe
the wearout mechanism is increased leakage, but I'm not positive (may
also be reduced capacitance, or increased impedance).

Based upon the recommendations of Homie Cap-Man, I have an inventory of
Nichicon PW series - they run about 33 cents each in lots of 100, from
digikey. I (plan to) use the 10V ones (once my soldering tips arrive).
I've already got plenty of ms6119 boards with blown caps - which,
coincidently have 3 oozing fat "blown" caps all in the same exact place on
the board (These boards were used with either P2-266 or P2-350 processors
only)...

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

Something interesting happened, just thought I should document it.

I tested an nvidia fx5200 128MB PCI video card in the P2B, running quake3
and 3dmark2k1 for benchmarks, which ran fine. I swapped my gf3 ti200 64MB
AGP card back in, and attempted to run 3dmark2k1, but it caused the system
to reset.

So, I swapped the fx5200 PCI in and ran memtest test #6, but it also
rebooted at 2%...

Not too sure it means anything, but just thought I'd write it down - so
3dmark2k1 may or may not exhibit the reboot problem for you.

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

Something interesting happened, just thought I should document it.

I tested an nvidia fx5200 128MB PCI video card in the P2B, running quake3
and 3dmark2k1 for benchmarks, which ran fine. I swapped my gf3 ti200 64MB
AGP card back in, and attempted to run 3dmark2k1, but it caused the system
to reset.

So, I swapped the fx5200 PCI in and ran memtest test #6, but it also
rebooted at 2%...

Not too sure it means anything, but just thought I'd write it down - so
3dmark2k1 may or may not exhibit the reboot problem for you.

I'm pretty sure I've run 3dmark01se before, but I'll try it again
(weekend).
You didn't forget to set AGP divider to 2/3 though (in case you've used
a 100Mhz FSB cpu)?

 

[Ixnei]

You didn't forget to set AGP divider to 2/3 though (in case you've used
a 100Mhz FSB cpu)?

It's set at 2/3.

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

On Mon, 26 Apr 2004 22:18:06 -0400, P2B wrote:
[snip]

Might be worth trying it without G35 to G37 - that's how I have my Asus
S370-DLs wired and they don't have this issue.

It appears that Roland is not using this one, but having the problem
still:

*****

... In particular, quite a few people connected G35 (Vtt) to G37 (vtt
only on tualatin) (which I didn't), ...

*****

Indeed, I didn't notice that until after I posted. My theories haven't
panned out too well so far :-(

At this point, IMHO it makes most sense to isolate the problem to the
board or slot adapter, by swapping in an adapter that's known not to
exhibit the problem - either a Slot-T or modded S370-DL. I have new
Slot-Ts in stock and would be happy to loan one or two if mailing costs
were covered.

[snip]


I personally prefer to use new capacitors, rather than those which have
been approaching the end of their useful lifetime. Most of these
capacitors are rated for lifetimes of 2-3,000 hours, which really isn't
that much "up-time" on a computer. The long-life ones maybe go out to
8,000 hours, which is just short of one year (at 24/7 'on'). I believe
the wearout mechanism is increased leakage, but I'm not positive (may
also be reduced capacitance, or increased impedance).

Absolutely agree, they are difficult to remove intact and not worth the
effort given new ones are economical. Used capacitors usually test at
significantly higher ESR than is specified on the datasheet.

Mind you, I have several P2B based systems which have run close to 24/7
for over 5 years with no sign of instability to date.

P2B

 

[Paul]

I've seen that the larger capacitors for a given uF/V rating have lower
impedance, so perhaps these smaller ones simply have higher impedance
values. Not sure what the consequences of this would be, other than maybe
worse switching response at high frequencies (it's been a while since
my AC daze)...

Check the datasheet for the 6019. It has some excellent hints
on what aspects of the design are important. For example, the PWM
section says:

"The bulk filter capacitor values are generally determined by
the ESR (effective series resistance) and ESL (effective
series inductance) parameters rather than actual capacitance."

Presumably the large number of caps is being used, to share the
ripple current flowing through the caps. Standard electrolytic
caps from many vendors have the same characteristics, and so the
size of a cap is a good indicator of its properties. Specialized
caps, like Sanyo OSCON (organic semiconductor ?) are many times
better at carrying ripple currents, and their size cannot be
directly compared to the standard composition caps.

Try to compare parameters for the old caps with the new, before
substituting them. And make sure you know which ones belong to
the PWM circuit, as opposed to the other circuits, as the rules
may be different for the other ones.

Something people don't realize, is too much output capacitance
on a regulator circuit can be just as bad as too little capacitance.
You can degrade the phase margin in the circuit by adding excessive
capacitance, and the regulator will oscillate when that happens.
A well spec'ed regulator circuit will actually come with
load curves, to tell you how much capacitance can be safely
added, before the regulator breaks into oscillations.

If the designers of the 6019 had put a latching fault pin per
power circuit, this problem would be easy to debug. Since the
only external indication is the one fault signal, the only way
to debug the circuit, is with a storage scope, triggered off
an edge of the fault signal.

HTH,
Paul