IRIX and Software

O2 As Serial Console: HOWTO

=======================
O2 As Serial Console: HOWTO
=======================


Edit 'inittab':

Edit '/etc/inittab' To Disable 'getty' On "Port 2":

Code: Select all

t2:23:off:/sbin/suattr -C CAP_FOWNER,CAP_DEVICE_MGT,CAP_DAC_WRITE+ip -c "exec /sbin/getty -N ttyd2 co_9600"      # port 2


If the third field in the line is the word 'off' (as in the example above), exit the file and continue with next step.

If the third field is the word 'on', change it to 'off'. Then save the file, exit, and at the shell prompt enter this command:

telinit q

Edit 'Devices':

Edit '/etc/uucp/Devices' To Enable A Direct Line On "Port 2":

Code: Select all

Direct ttyd2 - 9600 direct


Edit 'Systems':

Edit '/etc/uucp/Systems' To Enable Direct Connections On Any Time:

Code: Select all

Direct Any Direct 9600 -


Resultant Device Settings: [9600 8N1]

    9600 baud
    8 Data bits
    No Parity
    1 Stop bit

cu Syntax:

Code: Select all

cu -d -s 9600 -l /dev/ttyd2


...Or Simply:

Code: Select all

cu Direct


cu Conversation Commands:

man cu wrote: ~.
terminate the conversation.

~!
escape to an interactive shell on the local system.

~!cmd...
run cmd on the local system (via sh -c).

~$cmd...
run cmd locally and send its output to the remote
system.

~^Z
suspend the cu session. (^Z, control-Z, is the
current job control suspend character (see csh(1) and
stty(1)).

~%cd
change the directory on the local system. Note:
~!cd will cause the command to be run by a sub-shell,
probably not what was intended.

~%take from [ to ]
copy file from (on the remote system) to file to on
the local system. If to is omitted, the from
argument is used in both places. The shell commands
below are sent to the remote machine to cause it to
transmit the file. In fact, they are sent in a
single line with semicolons (;) between each command.

stty -echo
if test -r arg1; then
(echo '~>':arg2;cat arg1;echo '~>')
else
echo cant\'t open: arg1
fi
stty echo

~%put from [ to ]

copy file from (on local system) to file to on remote system. If to
is omitted, the from argument is used in both places.

For both ~%take and put commands, as each block of the file is
transferred, consecutive single digits are printed to the terminal.

The shell command line below is sent to the remote machine to cause
it to accept the data. Obviously, the shell on the remote machine
must be /bin/sh or a shell that correctly interpret these commands.

stty -echo;(cat - > arg2)||cat - >/dev/null;stty echo

~~ line
send the line ~ line to the remote system.

~%break
transmit a BREAK to the remote system (which can also be specified
as ~%b).

~%debug
toggles the -d debugging option on or off (which can also be
specified as ~%d).

~t
prints the values of the termio structure variables for the user's
terminal (useful for debugging).

~l
prints the values of the termio structure variables for the remote
communication line (useful for debugging).

~%nostop
toggles between DC3/DC1 input control protocol and no input control.
This is useful in case the remote system is one which does not
respond properly to the DC3 and DC1 characters.
Another Tip:
...the right cable to connect a DB-9 based SGI Workstation as serial console is slightly more complex than the one required to connect a Characters Terminal:

DIN-8 to DB9F Server-to-Workstation Serial Cable

It will work to use a Challenge S as server, connected to a Challenge, Onyx, Personal IRIS, or Power Series as workstation as replacement of serial console:

DIN-8 Signal DB9F Signal

Pin 1 Data Terminal Ready (DTR) Pin 8 DCD
Pin 2 Clear to Send (CTS) Pin 4 RTS
Pin 3 Transmit Data (TXD) Pin 3 RXD
Pin 4 Signal Ground (GND) Pin 7 GND
Pin 5 Receive Data (RXD) Pin 2 TXD
Pin 6 Request to Send (RTS) Pin 5 CTS
Pin 7 Data Carrier Detect (DCD) Pin 9 DTR
Pin 8 Signal Ground (GND) Pin 7 GND


You'll not getting working, unless you can buy/built one of theses.

[EDIT]
...Well, thanks to Jan-Japp I'll extend these list with the right pin-to-pin setup for the use with O2/Octane/Origin.
[EDIT]

The first and third column lists the alternative pin-to-pin setup that will work to use a Challenge S as server, connected to an O2, Octane, or Origin as workstation as replacement of serial console:

DIN-8M Signal DB9F-Onyx Signal DB9M-O2 Signal

Pin 1 Data Terminal Ready (DTR)---------- Pin 8 DCD Pin 1 DCD
Pin 2 Clear to Send (CTS)---------- Pin 4 RTS Pin 7 RTS
Pin 3 Transmit Data (TXD)---------- Pin 3 RXD Pin 2 RD
Pin 4 Signal Ground (GND)---------- Pin 7 GND Pin 5 GND
Pin 5 Receive Data (RXD)---------- Pin 2 TXD Pin 3 TD
Pin 6 Request to Send (RTS)---------- Pin 5 CTS Pin 8 CTS
Pin 7 Data Carrier Detect (DCD)---------- Pin 9 DTR Pin 4 DTR
Pin 8 Signal Ground (GND)---------- Pin 7 GND Pin 5 GND
GeneratriX wrote: ...the right cable to connect a DB-9 based SGI Workstation as serial console is slightly more complex than the one required to connect a Characters Terminal:

[...]

You'll not getting working, unless you can buy/built one of theses.


My experience is different.

A few years ago, I hacked together a serial cable for an Indy or Indigo2, and it didn't work properly.
I then disconnected all hardware flow control lines (only TX/RX and GND left, so the most basic serial null modem cable), and it worked.

I use a generic windows PC with HyperTerm to connect. Of course you have to disable hardware flow control before you try to connect.

These days, I have a bunch of cables:
1) DB9 => DB9 nullmodem (for O2 and Octane)
2) DB9 => mini-DIN8 nullmodem (for 4D/35, Indigo, Indy, Indigo2)
3) DB9 => DB9 (male->female, special wiring for 4D series, looks suspiciously like a serial extension cable).
4) A real serial extension (male->female) to reach boxen that are too far away otherwise.
I'm pretty sure none of #1 ... #3 has more than 3 wires inside.

What I should have done was something like this .
But when I need just one more cable, I get just that cable, rather than redoing the entire collection. But still, this is pretty ingenious. One day ....

Hope this helps.
Now this is a deep dark secret, so everybody keep it quiet :)
It turns out that when reset, the WD33C93 defaults to a SCSI ID of 0, and it was simpler to leave it that way... -- Dave Olson, in comp.sys.sgi

Currently in commercial service: Image :Onyx2: (2x) :O3x02L:
In the museum : almost every MIPS/IRIX system.
Wanted : GM1 board for Professional Series GT graphics (030-0076-003, 030-0076-004)
Quite a few PC-notebook models do without a serial port (COM port). In their place are USB ports.

Just wonder why those USB-COM adaptors failed to work properly with a working null modem cable.

For instance, I've tried one of those USB-COM adaptors to connect a PC (via hyper-terminal to an INDY) via a working null modem cable. The command monitor menu can be displayed in the hyper-terminal, i.e., the INDY can transmit signals and received by the PC (hyper-terminal) but NOT the other way round.

BTW, the null modem cable works perfectly when using the standard COM ports of a desktop PC.
jan-jaap wrote: My experience is different.

A few years ago, I hacked together a serial cable for an Indy or Indigo2, and it didn't work properly.
I then disconnected all hardware flow control lines (only TX/RX and GND left, so the most basic serial null modem cable), and it worked.

I use a generic windows PC with HyperTerm to connect. Of course you have to disable hardware flow control before you try to connect.


Thanks for these link Jan-Japp; it is alwys a really interesting piece of work to have as an off-line backup too! ;)
...Well, my experience using PC(s) as serial consoles confirms the your; since they seem to be a lot more serial-communications-friendly for this kind of jobs; and many times I've obtained success just adapting these cable that I have from my previous Wyse terminal (that I've used to admin a couple Indy(s)), adding just a home-built DB25F-DB25F converter at the end, and using on a PC the DB-25 COM port.

I've also used Indy and Indigo2 in replacement of serial console for SUN Sparcstation10 and SparcstationLX, with three-wire (RX-TX, TX-RX, GND-GND) cables.

I can recall also a problem on an old server that I've used to have (Intel Columbus-II, R-440LX Motherboard, Dual Pentium II 333MHZ), on which you could not connect to an Indy if at least 8 lines were not wired. The problematic line was the Pin6/DSR signal on the DB-9 side, which needed to be wired to Pin1/DTR on the DIN8 side. Without this, you could not use an HyperTerminal on this server to admin an Indy/Indigo2.

But seems that connections between SGI(s) with different serial port layouts require to have those extra lines wired. In example when you use a DIN8M based workstation to be administrated by a DB9M based workstation as serial console, as in this case.

But there is also another variable to have in account: I've used here a DB25F-DB9F stock converter, which could be internally wired slightly different in fabric. That's the reason why I'm now building my own converter to probe it on about 10 minutes, using the layout from Chan's site! :P

Unaffortunately; today is not a workable day in Argentine, and bussiness are closed, so I can't run to buy the right stuff to assembly the needed cable, and I don't want to wait tomorrow to try it. But I have the parts to arrange an adapter for the Serial-Null-Modem previously used here.

[EDIT]
...I've tried again with the three-wires layout between O2/Indy. Does not works at all.
[/EDIT]
Excellent topic Diego + jan-jaap :D

should be turned to a sticky, i bet it'll come handy to O2 owners...
fu wrote: Excellent topic Diego + jan-jaap :D

should be turned to a sticky, i bet it'll come handy to O2 owners...


Thanks Fu; I've focussed in O2 as serial console to Indy as headless system, just because actually it is the case that motivated this post from me. But all the above is useful for an user/owner of any SGI system, just altering the port numbers if needed, or changing the kind of Serial-Null-Modem cable if the connectors are different.

Oh; and if you recall that both machines at the ends of the cable must be in working condition, it will work! :P
That was the fail in this particular case, since I have no luck by now here with these Indy, because his DALLAS chip is dead, and the ones I've received from MAXIM through an U.S. guy are both of the wrong chip type... :(
...Oh well! No luck with these box.

[EDIT]
...But stills my suggestion to use the "Full Version" of the Serial-Null-Modem cable, as the one detailed above, wich probedly works between systems with different Port standards.
[/EDIT]