FAS 2.08 and Open Desktop ?? Anybody ?

[Warren Tucker]

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 at lafayet.UUCP> rob at 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 at 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