Re: TOP Network Interface Port of a Sun Ultra 30

On 2008-08-02, Barry L. Bond <barry@xxxxxxxxxxxxxxxxxxx> wrote:

Hi DoN (and others)!

An update: yesterday afternoon, I got some questions answered, and I
now know what I'm going to do to have serial ports on my Linux system
again. (The Cyclades YeP/DB25 I have is no longer even repaired. I will
be getting a new -- now Avocent -- device which connects to a network to
allow up to 16 serial connections.)

O.K. How many things connected to that original serial card have
been damaged too?

Connect between two terminals with a null modem and cable and
see whether information typed on one keyboard shows up on the other,
then go to the other keyboard and repeat. Once you have two known good
terminals, you can use one of them for testing the rest of the
terminals.

So, this is finally decided, and I'm going to order it probably
Monday or Tuesday and get it started here. That will allow me to use the
7 terminals, X-10 power controller,

If you had an X-10 connected to the system, it also may be
damaged. Actually, it is more likely to have been damaged than anything
else other than modems.

UPS, speech synthesizer, all kinds of
things I have connected to serial ports again.

So, this morning, right after midnight, I started with the Sun.

I don't use Solaris 8 -- I'm using Solaris 10 these days. But
there should be diagnostics on the OBP -- before you ever get into the
OS. You'll probably want to hook another system to the ttya serial port
to see all of the output.

The "printenv" of my output already shows diag-level to be max. I
did switch diag-switch? to true and powered back on. (I was just looking
at things. I did not have output to another device, yet.)

You want that because there is usually some information output
to the serial port before it wakes up the graphics card and monitor.

It powered on, and it was longer than normal before I saw any output
on the monitor, but I did eventually see output.

Part of that was because it was doing a more exhaustive check of
RAM. Part of it was probably because there was other information sent
to the serial port before it got around to seeing the keyboard and
switching output to the monitor.

It proceeded. Now, I let it run about an hour. It appeared that it
*may* have been stuck on the network... setting network link and speed,
down, contact your system administrator... (I like this, since that's
me!) :-D

Hmm ... in your eeprom settings, do you have the following one
set as shown here:

diag-device=net

if so, it will try to boot from the net since you have diag-mode? turned
on. Set it to "disk0" or "disk1" and it will try to boot from hard
disk in the system. And, if "diag-file" is set to a specific bootable
program, it will boot that to try to do more diagnostics -- checking the
disks and the network as the particular program is configured to test.

After 1:00 this morning, I tried hooking the first of the two
serial/RS232 sessions of my DEC VT330 terminal which sits on my desk to
it. (It has two sessions.)

Two "sessions"? Do you mean two serial ports which can be
selected from the setup mode?

I went into its setup and set the baud rate to 9600. It was already
set to 8 bits, no parity, 1 stop bit.

However, I see NO OUTPUT AT ALL, on the terminal when I do this.

Did you have a null modem? Both the terminal and the computer
are wired as DTE (in spite of the DEC having a male DB-25 and the Sun a
female DB-25). You need to connect pin 7 together, and to cross over
pin 2 at one end to pin 3 at the other and vice versa.

For that matter -- do you know that the terminal is still good?
If it were connected when the lighting struck, it may have damaged the
serial port circuitry on the terminal. For a quick check, connect pin 2
to pin 3 and see if what you type shows up on the screen.

Close to 2:00 this morning, I HAD to get to bed. I just powered it
off.

I googled this morning to determine how to get back to the DEFAULT
settings of screen and keyboard for output-device and input-device. (I
see holding <STOP> and <N> on the keyboard as you power it on does that,
and it did. :-)

:-)

Just now, I moved it to TTYB. And, I am using a different terminal,
a VT220.

So we don't know which of the two has the problems. I presume
that you set output-device and input-device to ttyb -- and remembered to
check the serial parameters for ttyb, which are separate from ttya.

I tried a "null modem" adapter in the line.

Aha -- finally -- so you did not have a null modem to start
with.

When I powered up after putting the "null modem" in the line on TTYB,
I got what my mother says "it looks like Greek to me". It appears to be a
couple of lines of "garbage characters", which we also sometimes get after
a close lightning strike the first time we try to log in on a terminal.

Typically a sign of differing baud rates on the two devices
talking to each other.

It will say login, normally. We type our name and that appears,
normally. Then, when we hit <RETURN>, a few garbage characters show up,
and we just let the login time out (60 seconds) and when it does, and asks
for login again, all is well.

Note that depending on the settings in /etc/ttydefs you could
have "autobaud" enabled (only for a booted system, not for OBP), which
will switch baud rates every time you hit "BREAK" until you have been
able to recognize the login request and successfully log in.

(I have serial surge protection on my serial lines -- especially the
lines that go from the office to other rooms in the house, because the
line is from about the electrical outlet let, and then go up into the
attic, where we have an "inverted U" and then they go down into another
wall in some other room of the house, down to about electrical outlet
level -- a perfect antenna for lightning's energy! :-) We still see
this, but it has never been a problem. It is a normal thing we see, and
have always seen.)

Hmm ... sounds like an excellent place to use fiber optics and
RS-232 to fiber modems right at the terminals and modems. This protects
the serial ports from being zapped.

I have 7 terminals throughout the house. However, none of them have
been used -- so far as the serial connection is concerned, because the
Linux serial card (supporting 16 serial ports) was also damaged. (As I
indicated above, I will be ordering a new product that will replace this
early this next week, so I hope to have that resolved soon.)

*Test* those terminals to make sure that they all work.

ALL RIGHT! I SEE OUTPUT on the VT220 terminal!

And, it looks quite similar to the output I saw last night when I let
it run still outputting to the screen.

O.K.

I probably will just let it run here, all day long, if need be.

It did a lot of output which looks "interesting" and looks possibly
okay...

But eventually, here is what I am seeing...

<<>>
Using onboard Transciever - Timeout waiting for AutoNegotiation status to
be updated.
Timeout reading Link Status. Check cable and try again.
<it does this three times, and then>
AutoNegoation Timeout.
Check cable or contact your System Administrator.
<<>>

This appears to just continue. It appears to switch back and forth
between network and ARP...

You probably have the "diag-device" set to "net" so it will try
and try and try until it either gets there or is powered down. :-)

It would be nice if I could "capture" this output! :-O I have to
leave with my mother in a few minutes. I will just let this run, but if
something "serious" is output, and if I would be able to interpret that, I
might would miss it...

Capture requires another computer (or perhaps a serial printer)
connected to the computer while it is going through this. IIRC some DEC
terminals have provisions for a serial printer to be hooked to the
second serial port and you can set it up to log everything which shows
up on the screen.

I guess a question I have for you at this point is, is there a way to
tell the diag-switch? true running to "continue past" the network port
(which I know is bad), if this is possible?

Well ... at least turn "diag-device" to "disk" instead of "net"
and you may get rid of that.

(It looks like it may be stuck there, and isn't proceeding past it.
If it is possible to proceed past it to check the health of the rest of
the motherboard, how can I do that?

I think that it tries that after it has completed all of the
built-in tests -- to try to boot a separate diagnostics program specific
to the local practices and connections.

Good Luck,
DoN.

--
Email: <dnichols@xxxxxxxxxxx> | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---
.

Relevant Pages

  • Re: TOP Network Interface Port of a Sun Ultra 30
    ... now know what I'm going to do to have serial ports on my Linux system ... things I have connected to serial ports again. ... *may* have been stuck on the network... ... I have 7 terminals throughout the house. ...
    (comp.sys.sun.hardware)
  • Re: terminal server for vax?
    ... DECserver 90 series, or DECserver 700 series, or other similar options. ... session and the other serial ports are just treated as output ... LAT support builtin on the host side. ... something that was present only in DEC terminals. ...
    (comp.sys.dec)
  • Re: terminal server for vax?
    ... DECserver series terminal servers was chosen. ... DECserver 90 series, or DECserver 700 series, or other similar options. ... session and the other serial ports are just treated as output ... Multi-user basic would also use all the terminals as a kind of ...
    (comp.sys.dec)
  • Re: Serial Port Configuration
    ... and one of our most common problems is when ... Here in the Netherlands they are called EFT terminals or PIN pads. ... RS-232 serial ports are known to stop 'working' temporarily or even ...
    (comp.os.linux.hardware)
  • Re: Why are laptops no longer made with serial ports?
    ... Actually the question should be "Why are MOST laptops no ... longer made with serial ports?" ... etc. and among the connections on the back is ... As far as the 64 meg data card for the 176C, ...
    (sci.geo.satellite-nav)