abcscnge@csuna.csun.edu (Scott "The Pseudo-Hacker" Neugroschl) (06/25/89)
I have a VME bus box running System V. I have 18 serial ports: (/dev/console, /dev/tty01, /dev/tty[12][1-8]). On /dev/tty18, I have a direct connection (via genderchangers/nullmodems) to a true blue AT 339 running SCO Xenix/286 2.2.1. (the VME serial ports are MVME332XT boards). Here's the problem: I have uugetty running in my inittab on tty18. ps -ef shows NO associated terminal for the uugetty, i.e. $ ps -ef UID PID PPID C STIME TTY TIME COMMAND ... root 27303 1 0 00:43:47 ? 0:00 /etc/uugetty -r -t 60 tty18 9600 ... Other uugettys or straight gettys (tty17, or tty27, for example) have the correct associated tty. The problem is that the AT can't call up the VME box for UUCP purposes, because no login prompt is received. HELP!!!!!! -- Scott "The Pseudo-Hacker" Neugroschl UUCP: ...!sm.unisys.com!csun!csuna.csun.edu!abcscnge -- Beat me, Whip me, make me code in Ada -- Disclaimers? We don't need no stinking disclaimers!!!
dg@lakart.UUCP (David Goodenough) (06/26/89)
abcscnge@csuna.csun.edu (Scott "The Pseudo-Hacker" Neugroschl) sez: > I have a VME bus box running System V. I have 18 serial ports: > (/dev/console, /dev/tty01, /dev/tty[12][1-8]). On /dev/tty18, > I have a direct connection (via genderchangers/nullmodems) to a > true blue AT 339 running SCO Xenix/286 2.2.1. (the VME serial > ports are MVME332XT boards). > > Here's the problem: I have uugetty running in my inittab on tty18. > ps -ef shows NO associated terminal for the uugetty, i.e. > > $ ps -ef > UID PID PPID C STIME TTY TIME COMMAND > ... > root 27303 1 0 00:43:47 ? 0:00 /etc/uugetty -r -t 60 tty18 9600 > ... > > Other uugettys or straight gettys (tty17, or tty27, for example) have > the correct associated tty. The problem is that the AT can't call up > the VME box for UUCP purposes, because no login prompt is received. Hummmm. Sounds a bit like our ISI running BSD 4.3. Here's some output from a ps ax: PID TT STAT TIME COMMAND ....... 160 ? I 0:00 - std.9600 ttyh0 (/etc/getty) 163 ? I 0:00 - std.9600 ttyh3 (/etc/getty) 165 ? I 0:00 - std.9600 ttyh5 (/etc/getty) 166 ? I 0:00 - std.9600 ttyh6 (/etc/getty) ....... 173 ? I 0:00 - A2400 ttydx (/etc/getty) 158 co I 0:00 - std.9600 console (/etc/getty) 161 h1 I 0:00 - std.9600 ttyh1 (/etc/getty) 162 h2 I 0:00 - std.9600 ttyh2 (/etc/getty) ....... Odd that. Well it just so happens that the console, ttyh1, and ttyh2 are the only ports with terminals plugged in (except ttyh4, where I am right now :-) ). So I'm guessing (comments anyone) that the getty doesn't print a prompt or "attach" itself till after CD rises. Note that ttydx is attached to our modem, which currently is hung up. Try getting one of those serial line monitor widgets from Radio Shack, plug it in, and see what you have where. _POSSIBLY_ looping 20 (DTR) to 8 (CD) will work, although it may have unpleasnt side effects if the getty is always awake (in particular calling out may get a bit touchy). Also check pin 6 (DSR), you might need to loop there, rather than pin 8. -- dg@lakart.UUCP - David Goodenough +---+ IHS | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@xait.xerox.com +---+
limes@sun.com (Greg Limes) (06/30/89)
[showing off my ignorance to the world again, but what's new]
In article <2048@csuna.csun.edu> abcscnge@csuna.csun.edu (Scott "The
Pseudo-Hacker" Neugroschl) complains about his System-V box starting a
getty for a serial port, and having a "ps -ef" line that reflects that
its controlling TTY is "?".
Scott, all my experience is on BSDish boxes, but it seems to me that
this would be the same across both sides of the world. Commonly, this
happens when the "getty" is attempting to open a serial port with
hardware carrier detect set up, and is being blocked in the open()
call until the serial line's DCD line.
Look carefully at where the genederchangers and nullmodems end up
connecting pin 8 on your VME box's interface. This is probably the
signal that needs to be asserted before your getty is freed to
execute. This is just a guess, it may be pin 6 or even somewhere
strange; check your documentation for specifics.
If your AT box is kind enough to assert DTR only when the port is
open, connect the PC's DTR (probably on pin 20) to the VME's DCD
(again, probably on pin 8); when the PC "dials up" the VME, it will
open the gates for the getty. The benefit of this arrangement is that
if the PC hangs up (drops DTR), the session on the VME box will
(probably) be killed off.
This is all generalizing from another varient of unix, thus all the
weasal wording ... hope it puts you onto the track of the problem.
-- Greg Limes [limes@sun.com]
Nearly Reformed Hacker
--
Greg Limes limes@sun.com ...!sun!limes 73327,2473 [chose one]