Antonio, you're giving me hope. So, I will check the 5 V output
with the scope, see if there are any spikes.
The funny thing is, the other boards in the VAXBI cage seemed
to be alive and well (after being put into my working bus.)
I do remember having tried that particular VAX just about last
year and indeed it did work then. So, something happened either
during the move downstairs or may be dust has entered the
backplane contacts.
Question: if only the XMI side is in the self test will fail,
as you noted. But how can I discern if it fails just because
of the missing BI side or whether it's the XMI side card
itself?
One thing I noticed with some XBIA cards was that after the
CPUs were initialized and they were probing the adapters on the
XMI bus (I guess) all CPU's yellow and red lights would
suddenly turn off, while the memory LEDs were still on. That
looks to me like serious business, probably the DC regulator
overloaded and shutting down (memory has its own DC regulator
so it stays on.) I always turned off power right away so I
didn't get to look at the indicator LEDs in the back on the
DC regulators. Scary stuff, but you gave me hope.
thanks,
-Gunther
Antonio Carlini wrote:
>>Normally, a machine that damages boards has got PSU problems (the 5V rail
>>sitting at 12V or something). Do you know what the outputs of the PSU
>>should be and can you check them? (use a 'scope as well if you have one
>>to look for HV ripple on the output -- a common failure mode of SMPSUs is
>>a high ESR (or open) output capacitor and you can then get 10-20V spikes
>>on the 5V output...).
>>
>
> I no longer have one to look at, but from memory, the
> 6K regulators are at the back and the outputs are
> shielded by transparent plastic covers. Should be easy
> enough to remove these and 'scope away. Note however,
> that these are there for protection: the voltage is low
> but the current is high - remove metal from body before
> trying this out!
>
>
>>One board damaging another is less common unless some component failure
>>is shorting one of the pins to a supply line or ground. It can happen (as
>>here). Do you know what to expect on each pin (I guess not, as AFAIK DEC
>>never published real technical documentation for the VAX 6000 series).
>>
>
> The 6000 tech manuals tended to concentrate on the
> programming aspects. There was an XMI handbook which
> covered the bus signals and protocol in some detail.
>
>
>>If there are any recognisable chips on the boards (especially bus
>>buffers), check them. And if there are picofuses for the supply lines
>>(some machines have them, I have no idea if the VAX 6000 is one of them),
>>check those too. It's not unheard-of for a bus short to blow a fuse and
>>not damage much else.
>>
>
> The XMI connection was handled by a dedicated chip
> (in the "XMI corner") with possibly a few drivers and such
> strung around it (much the same concept as with the
> VAXBI bus).
>
> I would be surprised if a dead XBIA managed to
> also take out an associated XBIB. There are rules about
> which boards can go in which slots etc. I had
> a few "funny turns" with my 6K but it always turned out
> to be a badly seated board, or a missing cable
> or the problem being somewhere else and me being
> in a rush.
>
> My first step would be to ignore the VAXBI,
> remove as many boards as are needed to get the
> thing to start at all (which in this case seems
> to mean remove the BI-XMI interface boards) and
> then add in the XMI end of the interface. Now
> try to run diags and see whether the board is
> even partially alive. (Obviously it will fail the
> tests that go look for the other end of the
> interface). If OK so far, empty the VAXBI cage
> and add in the BI end of the interface board,
> properly hooked up. Pay careful attention to
> the transition headers and plugs on the BI
> and XMI interfaces. Now see if the diags are
> happy or not. If OK, season with further
> BI boards.
>
> I did this a few times myself and always
> ended up with a full set of working
> boards. Maybe I was lucky, maybe there really
> were problems with boards being badly seated
> or maybe I had a marginal board or two.
> Since all my problems happened when I needed
> to reconfigure the hardware, I assumed it was
> just seating rather than marginal hardware.
>
> Antonio
>
--
Gunther Schadow, M.D., Ph.D. gschadow_at_regenstrief.org
Medical Information Scientist Regenstrief Institute for Health Care
Adjunct Assistant Professor Indiana University School of Medicine
tel:1(317)630-7960 http://aurora.regenstrief.org
Received on Thu May 30 2002 - 23:23:03 BST