[comp.unix.sysv386] FAS 2.08 and Open Desktop ?? Anybody ?

rob@lafayet.UUCP (Rob Freyder) (02/08/91)

I just installed FAS 2.08 under ODT 1.0 and I have some questions. But first
some background.

I installed per Installation and Readme docs using defaults ..
I installed the com1 and com2 drivers.  
I removed the braindamaged sio drivers supplied by SCO.  
I used the same major device number that SCO used ... 5
I am using a Telebit T2500 with GE7.00 chips.  

Boot up codes appear to tell me that I have the 16540 chip installed.
I am not sure if I am reading this correctly and that part of the doc is
rather vague.

Dialing out Works great !!  Its nice to be back at 19200 ! (I poll for news)

The problem is with dial in.  DTR drops as soon as CD comes up.  If I do
something ridiculous like use getty instead of uugetty I am able to log
in with cu and uucp connections.  sub-optimal to say the least.

Can any of you odt/fas admins help me on this one ??  

How about sending your minor device numbers for ttyF* and maybe your
stty settings in gettydefs as well. I sure would appreciate it !

I'd sooner poll my sites and give up dialing in to keep this setup.
I cant bring myself to reinstall the crap from SCO .. I know I am close.

Thanks for any help or pointers you can give.

Rob.
-- 
 ____    ____     ____                       Core Lab - Western Atlas Int'l INC
 \   \  /   /\   /    \     Rob              Humans     (318) 235-9431
  \   /   /\  \/   /\  \    Freyder          Internet   rob@lafayet.waii.com
   \/___/   \/___/   \__\                    Bang    ...!uunet!lafayet!rob

gemini@geminix.in-berlin.de (Uwe Doering) (02/12/91)

rob@lafayet.UUCP (Rob Freyder) writes:

>The problem is with dial in.  DTR drops as soon as CD comes up.  If I do
>something ridiculous like use getty instead of uugetty I am able to log
>in with cu and uucp connections.  sub-optimal to say the least.

Rob, I tried to address your problem via e-mail, but it bounced.

Why is using getty less than optimal? FAS, with it's dial-in/dial-out
feature, is designed for getty use. What's so special about your uugetty
that you can't switch to getty? I don't know the SCO uugetty, but the
standard uugetty on most SysVr3 releases doesn't have any features
that getty doesn't have, except that you can dial out while uugetty
waits for a dial-in. Actually, most implementations of uugetty are
brain dead, anyway.

With FAS, you put getty on the port with the minor device number
208 + port#, and do the dial-outs on the device with minor device
number 80 + port#. No need to use uugetty anymore. Note that you
need to use the `-h' flag for getty to prevent a hang-up on
dial in. At first, I thought that this was the reason for your
problem, but as you used uugetty, I really don't know what
the cause of your uugetty hang-ups could be.

      Uwe
-- 
Uwe Doering  |  INET : gemini@geminix.in-berlin.de
Berlin       |----------------------------------------------------------------
Germany      |  UUCP : ...!unido!fub!geminix.in-berlin.de!gemini

wht@n4hgf.Mt-Park.GA.US (Warren Tucker) (02/26/91)

I received the referenced article dated 7 Feb just today, with a
layfatet.UUCP message ID, suggesting that some stale (backwater?)
site has repeated this news article.  Site wrdis01 got the article twice,
with mips apparently repeating it:
-> Path: n4hgf!kd4nc!emory!wrdis01!mips!wrdis01!news.cs.indiana.edu!
-> att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!
-> samsung!rex!rouge!lafayet!rob
It is the first time, I've seen this original article though I replied
to a reply to it some time in the past.

In article <1610@lafayet.UUCP> rob@lafayet.UUCP (Rob Freyder) writes:
>
>I just installed FAS 2.08 under ODT 1.0 and I have some questions. But first
>some background.
>
>I installed per Installation and Readme docs using defaults ..
>I installed the com1 and com2 drivers.  
>I removed the braindamaged sio drivers supplied by SCO.  

First of all, Rob, sio is not braindamaged.  It is one of the
better drivers in commercially available products.  It may be
crippled, but here is nothing wrong with its *brain* at all.  Sio
recognizes many kinds of boards without kernel relinking.  Maybe
a semantic point to you, but the fact it fails to sustain the 521
MICROsecond interrupt response time necessary to support 19200
baud streaming I/O on a one-deep receiver better suggests a limp
than dire neural pathology.

>I used the same major device number that SCO used ... 5
>I am using a Telebit T2500 with GE7.00 chips.  

What kind of serial port do you believe you are you using in the
machine?  You mention COM1 and COM2.  I guess this is the vendor
supplied board. What vendor and what CPU speed?

>Boot up codes appear to tell me that I have the 16540 chip installed.
>I am not sure if I am reading this correctly and that part of the doc is
>rather vague.

If you have done nothing other than unwrap a conventional 386
box, you probably do have a 16450.  'type=*' in the FAS boot
message is clearly documented as a indication that you do.  Is
this what you are seeing?

>The problem is with dial in.  DTR drops as soon as CD comes up.  If I do
>something ridiculous like use getty instead of uugetty I am able to log
>in with cu and uucp connections.  sub-optimal to say the least.

First, to dispose of the latter point, there is nothing
inherently wrong with using getty over uugetty.  SCO's getty
handles the full shared modem requirement.  Uugetty is supplied
for compatibility, but need not be employed.

Your actual point is puzzling (I cannot recreate it).  DTR is
only dropped when the line has been closed by all processes or
*any* process issues a TCSETA ioctl with the CBAUD part of a
termio c_flag to zero (B0).  It sounds like your getty is going
away on DCD or setting B0 (gettydefs problem?).

>
>Can any of you odt/fas admins help me on this one ??  
>
>How about sending your minor device numbers for ttyF* and maybe your
>stty settings in gettydefs as well. I sure would appreciate it !

********************************
The gettydefs I use for a T2500:
********************************

# 3: 2400->19200->1200->9600 baud cycle	(dialin modems)
3 # B2400 HUPCL OPOST CR0 ECHOE NL1 #
	B2400 CS8 SANE HUPCL TAB3 ECHOE IXANY #Mountain Park\r\n\nlogin: # 3a

3a# EXTA HUPCL OPOST CR0 ECHOE NL1 #
	EXTA CS8 SANE HUPCL TAB3 ECHOE IXANY #Mountain Park\r\n\nlogin: # 3b

3b# B1200 HUPCL OPOST CR0 ECHOE NL1 #
	B1200 CS8 SANE HUPCL TAB3 ECHOE IXANY #Mountain Park\r\n\nlogin: # 3c

3c# B9600 HUPCL OPOST CR0 ECHOE NL1 #
	B9600 CS8 SANE HUPCL TAB3 ECHOE IXANY #Mountain Park\r\n\nlogin: # 3

Improper coding of the 2nd stty line could cause you trouble.
Note  'B19200' is not recognized by the standard ATT getty code.
Using it in lieu of EXTA will result in B0, causing DTR to go away.

It would be nice if there were some notification getty could make
saying it had found bogus gettydefs data.  The most obvious choice,
mailing to root, would quickly fill up your spool partition if you made
a change and left for the weekend.

Fortunately,
    /etc/getty -c /etc/gettydefs | more
will show you *exactly* how it interprets the file.  A very minor
bug in the feature treats the comments at the top of the file
as 'Entry too long', but you may ignore this.

Properly, I guess you should edit a *copy* of gettydefs, check it with
    /etc/getty -c gettydefs.copy
and then, when it is correct, 
	mv gettydefs.copy /etc/gettydefs
    kill -9 all_idle_gettys
but hey, this isn't brain surgery, just minor podiatry, right?
(I wonder if getty reexamines gettydefs after DCD to find the
2nd termio setting or if it gets both values on it's initial
search; killing the idle gettys would ensure proper effect, though).

********************
/etc/conf/node.d/fas   (I don't use Uwe's device names; this is the
********************   config for a standard COM1 and Digiboard COM-8;
                       these are, however, Uwe's default minor numbers)
fas	tty1a	c	80
fas	tty1A	c	208
fas	tty2a	c	81
fas	tty2b	c	82
fas	tty2c	c	83
fas	tty2d	c	84
fas	tty2e	c	85
fas	tty2f	c	86
fas	tty2g	c	87
fas	tty2h	c	88
fas	tty2A	c	209
fas	tty2B	c	210
fas	tty2C	c	211
fas	tty2D	c	212
fas	tty2E	c	213
fas	tty2F	c	214
fas	tty2G	c	215
fas	tty2H	c	216

There are no minor number choices which should affect FAS behavior
in responding to a DCD rising edge.

>I'd sooner poll my sites and give up dialing in to keep this setup.
>I cant bring myself to reinstall the crap from SCO .. I know I am close.

All except on the 'crap' part, bud.  Wake up and smell the bit bucket.
 
-----------------------------------------------------------------------
Warren Tucker, TuckerWare   gatech!n4hgf!wht or wht@n4hgf.Mt-Park.GA.US
Many [Nobel physics] prizes  have been given  to people for  telling us
the universe is not as simple as we thought it was. -Stephen Hawking in
A Brief History of Time     In computing, there are no such prizes. -me