Re: TOP Network Interface Port of a Sun Ultra 30

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

Hi DoN (and others)!

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

We think a lot alike! :-)

I had already told my mother, when the first time I tried getting
output on the terminal failed, that I didn't know whether it was ttya on
the Sun motherboard or the terminal itself.

I'll snip quite a bit here to get to the meat.

[ ... ]

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.

Actually, while I don't know whether it still "serially" talks to the
computer, the CP-290 itself is still working just fine!

The serial port part is the most likely to be damaged, of
course. :-)

[ ... ]

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

Thank you! I didn't know and wondered why getting output on another
device was preferred. :-)

Hmm ... you have the DIN connector for the older Sun keyboards,
so you don't have as long before some things can happen. The USB ones
have to wait until the USB wakes up during POST.

Yes, I notice a light on the bottom of the flat-panel monitor
attached to the Sun turns from "yellowish" to blue after some amount of
time. (Again, longer than normal, but it does happen.)

O.K. The color change does not happen on mine, but I don't have
an Ultra-30.

When I see that, I now can see output on the terminal.

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

diag-device=net

Indeed I do! :-)

So it will keep trying to boot from that. :-)

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.

I just set "diag-device" to "disk1" (which is the disk I boot off of,
it is the larger hard drive I put in the Sun a couple of years ago).

The "diag-file" is set to nothing.

O.K. So it will try to boot from the normal kernel.

Okay. I just set output-device and input-device to ttyb and
diag-switch? to true. Powering off the Sun...

[ ... ]

Powering the Sun back on...

Okay! After a longer-than normal time, it booted, "kind of"
normally...

I saw all the "normal" things I'm accustomed to seeing when the
system boots.

(By the way, after it booted, the monitor attached to the Sun has the
Common Desktop Environment normal login.) Neato! :-)

Good!

Here is what I saw that is not normal, that by now has scrolled off
the terminal screen...

I saw "Starting apcupsd management ... Done"
and then a couple of lines later "Stopping apcupsd management". But,
then, it did a "Starting" again and it has remained started.

The explanation for that COULD BE the APC 750XL Smart-UPS is among
the things on that Linux serial connection, which of course is not
currently available. The UPS communicates with the Linux as the "master"
and the Sun as the "slave". When there is any power fluctuation or outage
that causes the UPS to come on (that is the battery-backed portion of it),
I get a long email from the Linux computer, and a shorter email from the
Sun computer. (So, it is just network communication with the Sun, where
it is physically attached to the Linux.)

O.K. While you don't have it connected, you might want to go
into /etc/init.d and look for what the "apcupsd" startup script is
called. Probably "apcupsd". Then cd to /etc, and try this:

find rc?.d -name \*apcupsd -print

and note any output. It should identify the startup directories which
have links which invoke the script. You should see something like this
(run on my own UPS dameon's name for a BEST Power Systems UPS):

======================================================================
Katana:csu 0:51:46 # find rc?.d -name \*checkups -print
rc0.d/K00checkups
rc2.d/S00checkups
======================================================================

The one which starts with a 'K' in rc0.d turns off the chekups daemon
when shutting the system down. The one which starts with an 'S' starts
the checkups daemon when the system enters run level 2 during boot.

While you can't use it, change the 'S' to 's' (lowercase) and
the system won't try to turn it on. Remember to change it back when you
are all fixed. You can also turn it off manually by typing:

======================================================================
sh /etc/init.d/apcupsd stop
======================================================================

but it will restart next reboot.

If the battery were to get close to being fully discharged (which is
about 50 minutes), both systems would shut down.

The BEST reports to the daemon how many minutes of run time is
left, and the daemon is told at start time how many minutes before
battery discharge to shut down the computer. The UPS then shuts itself
off too, to save the battery from deep discharge which could shorten its
life.

A *real* test of this hasn't occurred. Though in the middle of last
year (2007), we had a power failure that lasted about 40 minutes. The
systems just kept going like nothing had happened. (It's a good thing...
we weren't home at the time!) :-)

Well ... before I added another couple of UPS to the collection
(the servers were all on a 2KVA one, but my wife's and my workstations
were not on UPS at all) we had a long outage from a major thunderstorm
with some tornados in the area. It was off for a lot of time, came back
on about 5:00 AM, so I rebooted everything and went to bed, and about
10:00 it went out again, so we got no use out of those few hours while
we were sleeping, so we were without anything for about 24 hours from
first outage to final recovery.

So, anyway, it did a "Starting" of it again, and it has remained
started, because now I see an occasional line:

<<>>
Aug 3 16:18:42 canaan apcupsd[323]: Master not responding.
<<>>

sh /etc/init.d/apcupsd stop

to shut that up until reboot.

And, how true that is! :-D

The only other "error" type thing I have seen are lines such as
these, excerpted:

<<>>
Aug 3 16:22:16 canaan hme: SUNW,hme0 : No response from Ethernet network : Link down -- cable problem?
Aug 3 16:24:20 canaan hme: SUNW,hme1 : No response from Ethernet network : Link down -- cable problem?
<<>>

And, both of those are understandable, to me. The hme0 is the port
that doesn't appear to be working at all any more.

Yep -- the built-in one.

It is the port where
the D-Link router and cable modem were attached, and both of those had to
be replaced.

And, hme1 is the port where the Linux computer is normally attached.
However, the Linux network port is currently connected to port 1 of the
D-Link router, which is how I currently have Internet connection. It is
NOT attached to the Sun, as it normally is.

So -- do you have a hub or enough ports on the router so you can
plug cables from both ports in? If so, the router (or hub if you have
one) should have LEDs to tell whether the ports are seeing signal from
the computer. And if the computer sees signal from the hub or router,
it should shut up about that. (Or -- if you have a crossover ethernet
cable, just plug it into both Sun ports, and each will see the other if
both are working. Of course it will complain later when it tries to
connect to other things, but this will verify that both ports still
work.

The pins for an ethernet crossover cable are:

Conn1 Conn2
1 3
2 6
3 1
6 2

and the others don't need to be connected at all.

And, the only other messages I see, occasionally scrolling onto the
terminal, are also completely understandable. Lines such as:

<<>>
Aug 3 16:27:37 canaan fetchmail[327]: couldn't find canonical DNS name of pop-server.cfl.rr.com
Aug 3 16:27:37 canaan fetchmail[327]: POP3 connection to pop-server.cfl.rr.com failed: temporary name server error

Yep -- and the crossover won't fix those -- but it will tell you
whether both are working.

If you verify through connecting to a hub or a router that only
the separate card (hme1) is working, then you need to turn off the hme0
by renaming /etc/hostname.hme0 to /etc/Hostname.hme0 (the upper-case
first letter will keep it form being used, but you can later rename it
when you add another ethernet card or replace the one which you have
with a single QFE card.

(By the way, on all of these, bear with me. There COULD be an error,
because I'm just typing them here.

Understood -- and I'm not reading them in detail -- just enough
to confirm what I expect, so I would probably miss a typo anyway.

Now, on these last messages, I still
see them on the terminal, so at least I could double-check what to type.
On that first thing about the "Starting apcupsd"... I couldn't remember
for sure what came next!) :-D

That's OK. Turn off the link(s) which start apcupsd (there may
be more than one -- in say /etc/rc2.d and /etc/rc3.d -- just look for
all which start with 'S'.

This is also something understandable. In fact, I normally see that,
if the Internet is down.

The Sun is my mail host. It runs fetchmail, and once every five
minutes, it checks with RoadRunner for email for me and my mother. If we
have email, it transfers it to the Sun hard drive, and deletes it from
Road Runner.

O.K. My e-mail is delivered directly to two mail hosts here in
the house -- but I have my own domain so I can do that.

(So, my email at the moment is not normal, and it is SO SLOW compared
to the way I normally do mail! But, I am using the Road Runner web page
to at least be able to read my email.) :-)

So, I get lines such as those two every five minutes; the next time
"fetchmail" wakes up and checks again.

O.K. Is fetchmail a daemon, or is it run from the ttytab? Turn
it off too -- wherever it is. If in the ttytab (root one at a guess,
unless there is a separate "mail" account for it) just use the
"crontab -e" command and add a '#' to the start of the line which turns
it on. If a daemon, shut it off like the apcupsd -- and keep notes of
what you turned off, where, and how, so you can restore them all when
everything works again.

I get the hme0 and hme1 lines every once in awhile, too. I expect
them.

Does that mean the motherboard is okay?

I don't know. At least some of the motherboard ethernet
circuitry is working -- but the real test is whether the connections to
the ethernet connector work. Try one of the tests I suggested above.

I will say again that the Sun computer APPEARED to work completely
normally -- except for not having the Internet connection. And, when I
first rebooted it after getting home from the lightning strike, when the
Linux and Sun were still network connected (and before I had to play with
the Linux network port to get it on the Internet), I had my email.

O.K. Which ethernet port did the mail come through -- and which
did the linux read it through?

I had received 27 Internet emails that day. And, the NFS mounted
portion of the Sun's hard drive was still normally usable from my Linux
running of "mutt". (And, gkrell also monitors constantly whether I have
any new emails, etc. This was working -- then.)

What do you think? Some other type of diagnosis, or experiment with
getting a new ethernet port for the Sun?

Try the tests which I mentioned above first. They are
quick-and-dirty -- especially if you already have an ethernet crossover
cable, Otherwise you need a hub or router with LEDs for the ports to see
whether the Sun is sending to them, and the Sun will tell you whether
it sees connections from outside. (You don't need *data* for this, just
connection link lights or the boot telling you that it sees the ports as
connected.

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.

Heh heh. No. I did not know whether I would need a null modem
adapter in this line, but I was trying both! :-)

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.

No. Correct. I am intending to FULLY TEST all the serial devices in
my house when I have serial connections again!

Start with testing the ones which you are using to test the
Sun. After all -- test equipment which doesn't work tells you nothing. :-)

I haven't done that "quick check" yet, though I still have one VT220
that appears to work, because it at this moment is receiving normal output
information from the Sun, if I press the <RETURN> key I see "canaan
console login:".

That is a good sign. This is connected to ttya or to ttyb?
If on ttyb swap to ttya and change the eeprom settings to make sure that
both work.

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.

Correct. I was aware that there were at least two different places
where the problem could have been.

And, yes. I NEED your "elementary" help with this Sun stuff, but I
know at least a little more about serial configuration parameters, so I
knew enough to have checked the serial stuff for ttyb, and to have set the
input-device and output-device to ttyb. :-D

O.K. I tend to be as complete as I can be, just to reduce the
number of exchanges of postings needed.

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.

Thank you. I had forgotten about this, but I did know it, like one
or two decades ago! :-O

:-)

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.

On the Linux system, it's /etc/inittab. And, I have them "hard
coded" to be 19200 BAUD -- the fastest these older terminals can go.

O.K. Note that there was a time when a modem running full bore
at 19.2K on a unix system could bring it to its knees (back in the 10
MHz 68010 CPU days). This is because each character requires a full
task switch to read the character and then another to go back to
whatever was running. :-)

[ ... ]

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.

Well, I don't have that, and at the moment, I haven't ever had a
problem relating to that. So, I may wait and see... :-)

Keep your eyes open for that on eBay. It could save you a
repeat of a lot of this.

(I can only replace or change a certain amount at a time. And, while
I am blessed and believe I have made it incredibly well to have been
directly struck, I do have enough to think about at this particular
moment.) :-)

Agreed.

I do have APC RS232 connectors. They attach like the null modem
adapter.

Are they supposed to protect from HV zaps?

I have them at all the terminals that are in different rooms
than my office -- where I use the very long "inverted U" cables to go from
outlet level in my office to the other room. And, I had them on the
serial board of my Linux Cyclades YeP/DB25, the board where my DB25 serial
connectors attached to the Linux, in the office.

O.K.

[ ... ]

On my VT330 terminal in my office, and on my mother's VT220 terminal
in her bedroom (where she does her FMS, my Financial Management System
programming I completed in 1988), I have a DEC LA75 printer attached to
both terminals. Either the VT330 in my office or the VT220 in her bedroom
can normally print to this terminal. (We both print our FMS reports on
this old LA75 printer, even though I have an HP All-in-one.)

Yesterday, I powered up the VT330 terminal in my office, and with it
attached to ttyb, I was getting the same output. I had this printer on
and attached, and I set it to "Auto Print". And, it didn't print.

And, it appears the terminal *may have* locked up. It continued
getting output from the Sun, but I couldn't go into setup by pressing the
setup key, something you can normally do any time.

It is probably waiting for the printer to signal that it can
accept characters (CTS). The terminal just sends characters on to the
printer without buffering them I think, so a printer not working means
the terminal locked up.

I'll be carefully evaluating these -- after my serial connections are
reestablished.

(I'm back to the VT220 terminal from my training room for the Sun
ttyb output, at the moment...)

Well ... at least turn "diag-device" to "disk" instead of "net"
and you may get rid of 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.

Indeed I did! See above! :-)

Good.

Don, I want to thank you for your PATIENCE. Often, when someone
truly knows things as you obviously do, they lack the PATIENCE to
carefully explain to someone else what to do.

I don't know why, but I like to explain things. :-)

I want to tell you once again, THANK YOU -- for everything!

You're welcome.

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

  • HP Designjet 500 on Sunos
    ... The Centronics port is connected to a Sun SPARCstation 5 running Sunon ... I need suggestions on getting this to work on the Sun connection. ...
    (comp.periphs.printers)
  • Re: OpenOffice problems
    ... On Sun, 23 Sep 2007, Christian Baer wrote: ... I only upgraded the port and that whole process ... on the same communications line connection. ...
    (freebsd-questions)
  • Re: Alternatives to those pre insulated butt joints
    ... I have used huge numbers of methods of connection including ... Which cables use soldered on terminals these days? ... If a terminal is fitted to the correct size wire, with the proper tooling, ...
    (uk.rec.cars.maintenance)
  • Re: Suggestion for a lexical (login mode via TCPIP)
    ... Not sure of it is the right one to modify or to add another one, but it would be useful to be able to get information on whether the user us coming in via FTP, TELNET, etc. ... This would also allow a LOGIN.COM to check if someone is coming in through a secure/SSL port for instance. ... For the HP SSH server, it seems to be undefined. ... forget about the possibility of virtual terminals. ...
    (comp.os.vms)
  • From LA - Plans for 2 new cruise ship terminals rile some in this port town
    ... Plans to build two new cruise ship terminals at the Port of Los ...
    (rec.travel.cruises)