[jwhat]

Hi Weblacky,

sorry to hear that.

I am running the "runalldiags" from the "Online Diagnostics" so I can see what it reports and provide you with update.

I hope you are able to find replacement V10/V12 soon.

Cheers from Oz,

jwhat/John.

[Raion]

Yeah, this us unfortunately the fate of many Fuel cards. I don't notice legions of Tezros with failed cards, though some exist since the Tezro NEVER shipped with a V10, only V12, and you do see those occasionally.

I do have a spare V12 for the Tezro, but as that's my only spare and these have gone up in price a lot... I don't know if I could find another cheap one like I did here.

[weblacky]

Okay, I've begun the process of buying a tested V10 from Doug at Mashek, fair price, when I actually Pay him, I'll take down the WTB.

I did a bunch more probing on the V10. A lot of stuff doesn't make sense in a new light...nor can I figure out what I shorted open that WAS originally shorted closed.

Here's the deal. I returned to the original DS1780 IC I removed from the V10. I was hoping I could figure out which pins/functions got damaged which would give me a direction. Well the ENTIRE IC was OPEN...I MEAN OPEN...ALL legs accept ground to ground had some very high resistance. Ohm and Diode tests...NIL. So nothing connected to nothing! Wow, I do not know what to make of that.

Okay that is odd, I decided to trace the legs on the installed IC and found a VERY interesting, but also hard to comprehend how it failed, fact. ALL the VCCs (even the monitored ones) on the DS1780 on the V10 I have, have resistor arrays right next to them that current limit and PROTECT the DS1780 inputs! They are 1K Ohm and they ALL seem to be intact! So they aren't damaged. I tested all the arrays directly around the IC. They are real tightly in tolerance of 1K and show tracks connected to the DS1780 IC. So not cooked and still limiting current!

I also found the test points for 3V, 5V and 12V on the V10...I also found most of the power pins in the smaller of the two edge card connectors. Two functions from the DS1780 IC are directly (without protection) hooked to the power edge card as special pins. I believe they were pin 11 VOUT/NTin - DAC output/NAND Tree Input and Reset line. Both are going directly to the XIO connector! So that COULD have come from the mainboard as an event. The 5V that runs the DS1780 COMES FROM THE XIO Connector directly and goes through a few decoupling caps (reverse side) and then a resistor in the 1K array before it gets to the IC...all intact!

Now the error I got when I original replaced the DS1780 on the V10 was L1 XIO 12V Bias voltage low...like ~2v. So the V10 was dragging down the XIO 12V connector voltage with a short.

Since the DS1780 runs under a whole voltage range, I figured using the VCC pin I knew and PCB ground was a good way of finding the short (I was not 100% right on this...but there WAS something in the path doing a huge current draw) It's possible it's something that draws from the 5V line...but I didn't find any converter circuit design there...so I don't know what I affected. It's possible whatever I affected had shorted voltage rail boundaries and made a jump? Unknown.

After the short went away during my 1V injection testing, the L1 no longer complains of the XIO 12v line being dragged down, but my injection was on the 5V line! So the only way that makes sense is if the IC I shorted (like a transistor or gate) used 5V as signalling for switching 12V?

But the V10 apparently doesn't respond to power-up. THe 12V rail is currently not shorted...no other rail is. So I'm looking for an open, I guess.


The only way I know to do that would be to get a duplicate card (I'm trying to buy a duplicate now) and try a Ohm reading on ALL pins to ground. even just the edge connector could give me an insight into an ohms reading that is "light", suggesting a cut-off circuit area. I could also try a diode test for the same reason.

Values won't be exact but they should be similar. I initially thought the 12V was being shorted due to the VRM circuit on the V10...but those ICs don't show as shorted and the dragged down voltage value wasn't so huge that I might consider the GPU itself it be shorted.

So the adventure continues, there may still be hope to fix my old card if I have a working duplicate and enough time/luck. Or at least to find out enough info to know if it looks like a minor and major thing.

I'm very hopeful that the Fuel mainboard and all itself is fine so that when I stick a new card in it...it don't have an instant issue.

Given that the env values looked good after fiddling with the V10 card...I'm extremely hopefully the issue/failure is now isolated to the V10 card as I'm also using a replacement PSU.

But given I have proven the DS1780 IC is DRIVEN off the 5V mainboard line...I can say their failure and ENV disease is likely related as I thought a couple years ago to PSU 5v wiggle, which could kill DS1780 ICs.

More to come, obviously as I'm this far in...

[jwhat]

Hi Weblacky,

FYI, I had a look at the online (installed in "/usr/diags/bin") "runalldiags" script (and run it) and it does not include any diagnostic for graphics sub-system (V10 / V12).

Ditto the offline tools (installed in "/stand") do not have any graphics sub-system diagnostics.

Cheers from Oz,

jwhat/John.

[weblacky]

I think you may have missed the options.

Read page 116 of the fuel manual, I think you have to have -normal or -extensive to run the graphics.

[jwhat]

Hi Weblacky,

yes I read the manual ;-) tried "-help", which is why I was surprised that script did not seem to explicitly have graphics diags as part of listed test:

<<START LIST>>
###### Start Diagnostic List ########################################
## List of available diagnostics. Structure is as follows:
## diagName = Name of the diagnostic ex: "grizzly"
## diagBin = Name of diagnostic binary ex: "griz_script"
## diagDesc = Short description of the diagnostic ex: "System Stress Test"
## diagFunc = Function that runs the diagnostic. (See below for documentation on the function)
## diagBasic = String to pass to diagFunc when script is in Basic mode. (Or "NORUN" if diag does not run in that mode)
## diagNormal = String to pass to diagFunc when script is in Normal mode. (Or "NORUN" if diag does not run in that mode)
## diagExt = String to pass to diagFunc when script is in Extensive mode. (Or "NORUN" if diag does not run in that mode)
##
## To add a diagnostic - add it to this list and create a function (towards the bottom) to create a command line
## See the diag section for information on what the function needs to do.
##
## Diags are executed in the order they appear on this list.

@diags = (
# olperi
{"diagName" => "olperi", "diagBin" => "olperi", "diagDesc" => "CPU Diagnostic", "diagFunc" => \&runOlperi, "diagBasic" => "lvl1", "diagNormal" => "lvl1", "diagExt" => "lvl2" },
# torpedo
{"diagName" => "torpedo", "diagBin" => "torpedo", "diagDesc" => "CPU Floating Point Unit Diagnostic", "diagFunc" => \&runTorpedo, "diagBasic" => "lvl1", "diagNormal" => "lvl1", "diagExt" => "lvl2" },
# olmem
{"diagName" => "olmem", "diagBin" => "olmem", "diagDesc" => "Online Memory Diagnostic (Check /var/adm/SYSLOG for error message)", "diagFunc" => \&runOlmem, "diagBasic" => "lvl1", "diagNormal" => "lvl1", "diagExt" => "lvl2" },
{"diagName" => "olcmt", "diagBin" => "olcmt", "diagDesc" => "Cache/Memory Test (Check /var/adm/SYSLOG for error message)", "diagFunc" => \&runOlcmt, "diagBasic" => "lvl1", "diagNormal" => "lvl1", "diagExt" => "lvl2" },
# oldisk
{"diagName" => "oldisk", "diagBin" => "oldisk", "diagDesc" => "Disk Diagnostic", "diagFunc" => \&runOldisk, "diagBasic" => "NORUN", "diagNormal" => "lvl1", "diagExt" => "lvl2" },
# olpci
{"diagName" => "olpci", "diagBin" => "olpci", "diagDesc" => "PCI Config Space Dump/Decode", "diagFunc" => \&runOlpci, "diagBasic" => "NORUN", "diagNormal" => "lvl1", "diagExt" => "lvl2" },
# olenet
{"diagName" => "olenet", "diagBin" => "olenet", "diagDesc" => "BaseIO Ethernet Diagnostic", "diagFunc" => \&runOlenet, "diagBasic" => "NORUN", "diagNormal" => "lvl1", "diagExt" => "lvl2" },
# olsio
{"diagName" => "olsio", "diagBin" => "olsio", "diagDesc" => "Serial Port Diagnostic", "diagFunc" => \&runOlsio, "diagBasic" => "NORUN", "diagNormal" => "lvl1", "diagExt" => "lvl2" },
# olrti
{"diagName" => "olrti", "diagBin" => "olrti", "diagDesc" => "Real Time Interrupt Test", "diagFunc" => \&runOlrti, "diagBasic" => "NORUN", "diagNormal" => "lvl1", "diagExt" => "lvl2" },
# olusb
{"diagName" => "olusb", "diagBin" => "olusb", "diagDesc" => "USB Diagnostic", "diagFunc" => \&runOlusb, "diagBasic" => "NORUN", "diagNormal" => "lvl1", "diagExt" => "lvl2" },
# olrtr
{"diagName" => "olrtr", "diagBin" => "olrtr", "diagDesc" => "Router Diagnostic", "diagFunc" => \&runOlrtr, "diagBasic" => "lvl1", "diagNormal" => "lvl1", "diagExt" => "lvl2" },
# pandora
{"diagName" => "pandora", "diagBin" => "pandora", "diagDesc" => "System Stress Test", "diagFunc" => \&runPandora, "diagBasic" => "lvl1", "diagNormal" => "lvl1", "diagExt" => "lvl2" },
# olvst
{"diagName" => "olvst", "diagBin" => "olvst", "diagDesc" => "Generic Network test using Sockets", "diagFunc" => \&runOlvst, "diagBasic" => "NORUN", "diagNormal" => "NORUN", "diagExt" => "lvl1" }

);
###### End Diagnostic List ##########################################
<<END LIST>>

The list is from the "runalldiags" script.

I was trying to find the individual test executable, as when I run the script I get crash in reboot on PCI test, even thought the "offliine" test goes ok...

Maybe the graphics is part of "pandora" stress test...

EDIT #1:
Ok ran just "pandora" and it reports will run: io tests, fpu tests, mem tests, gfx tests, ntwk tests
So it is the "pandora" stress test that has the graphics test.

Cheers from Oz,


jwhat/John.

[weblacky]

Wow, well thanks for trying...the manual isn't accurate. I clearly says graphics...so where's graphics!

Sigh.....it really shouldn't be this hard...

[jwhat]

Hi Weblacky,

you can now breath easy...

The GFX test is part of (Online) "pandora" stress test.

Cheers from Oz,

jwhat/John

[weblacky]

Hi Weblacky,

you can now breath easy...

The GFX test is part of (Online) "pandora" stress test.

Cheers from Oz,

jwhat/John

When you say part of, do you mean it showed you a picture and you have to see if something is wrong? Or did it actually say stuff like "checking the vram, checking texturing memory, checking blah blah blah.

[jwhat]

Hi Weblacky,

you need to be running X Server to get GFX test to run,

So I:
1. Started machine as usual
2. Open up terminal windows
3. Shutdown non essential services (sgi_apache, mediad etc)
4. cd'ed to /tmp
5. run /usr/diags/bin/pandora (no arguments, doing -help will bring up some help)
6. It reported running progress on various tests it was running
7. The GUI testing was evident by it doing some graphics stuff in top right of display
8. Reported final result

NOTE: you can redirect the output if you want to save log
It created a "sysinfo" file which had details of where it has written stuff to

So not very spectacular and not much in way of verbose output.

If you read the "runalldiags" script you will see that is essentially runs a little scripted loop, to put a spinning wheel on screen, but I think the script does not do much more than invoke the underlying individual test programs. It does "fork", so the programs run decoupled and then monitors them to see if any of the test programs "hang".

NOTE: I elected to just run this test as the PCI test crashes and the machine reboots ... so my previous test never got to pandora GFX test

Cheers from Oz,

jwhat/John.