[comp.unix.i386] FAS on SCO ODT ???

vlr@dynsim2.uucp (Vic Rice) (06/15/90)

Has anybody had any success implementing the FAS async driver under
SCO ODT (UNIX 5.3.2). 

I would really like to get this working, especially since SCO's 
uugetty is broken. This forces me to muck around with enable/disable
since I have only one serial port for both incoming and outgoing
traffic.

I have an ALR PowerVEISA w/ 386 and standard 2 port com board
(Everex Magic I/O). 

Does the SCO sio driver need to be disabled (SCO doesn't have an "asy"
driver as referenced in the docs) ? If so, how ?
It keeps telling me sio must be installed and active. 
If I leave sio active and just do "make install" for the FAS stuff,
the kernel rebuilds OK. However on reboot, the system hangs during
the startup just before the info appears for the serial hardware 
( you know- int vec, DMA, base addr, etc. ). Instead of displaying
the usual, an "F1" appears on the left of the screen and its 
"deep sleep" time.
 
Any help would be greatly appreciated.
-- 
Dr. Victor L. Rice
Litwin Process Automation

jpp@specialix.co.uk (John Pettitt) (06/15/90)

vlr@dynsim2.uucp (Vic Rice) writes:

>Has anybody had any success implementing the FAS async driver under
>SCO ODT (UNIX 5.3.2). 

>I would really like to get this working, especially since SCO's 
>uugetty is broken. This forces me to muck around with enable/disable
>since I have only one serial port for both incoming and outgoing
>traffic.

>I have an ALR PowerVEISA w/ 386 and standard 2 port com board
>(Everex Magic I/O). 

FAS should work (you wil need to change the Y to N in the sio driver
entry in /etc/conf/sdevice.d to remove the sco driver).

However sco uugetty is not broken,  we have 4 trailblazers on one
of our UNIX 3.2.0 systems working just fine with dialin and out on
the same line.

There are some weird things - then device name in inittab must match
the entry in Devices (i.e no /dev or both have /dev in them) and if
you select B38400 you get B0 which causes a hangup !


-- 
John Pettitt, Specialix International, 
Email: jpp@specialix.com Tel +44 (0) 9323 54254 Fax +44 (0) 9323 52781
Disclaimer: Me, say that ?  Never, it's a forged posting !

walter@mecky.UUCP (Walter Mecky) (06/16/90)

In article <1990Jun15.020958.594@dynsim2.uucp> vlr@dynsim2.uucp (Vic Rice) writes:
+ Has anybody had any success implementing the FAS async driver under
+ SCO ODT (UNIX 5.3.2). 
+ If I leave sio active and just do "make install" for the FAS stuff,
+ the kernel rebuilds OK. However on reboot, the system hangs during
+ the startup just before the info appears for the serial hardware 
+ ( you know- int vec, DMA, base addr, etc. ). Instead of displaying
+ the usual, an "F1" appears on the left of the screen and its 
+ "deep sleep" time.

In 25 Feb 90 andy@netcom.UUCP (Andrew Burgess) posted the same problem
and solved it by himself (Message-ID: <7854@netcom.UUCP>). Here the kernel
of his article:
> Here I go again responding to my own postings. I waded into the driver a
> little and found that fasinit() was calling a UART test routine that
> in turn called delay() to wait for characters to flow through the UART.
> According to the FM "delay cannot be called from an xxinit or interrupt
> routine". I stubbed the test routine out and the driver came up fine.

Hope the helps you too. Let us now.
-- 
Walter Mecky

wengland@stephsf.UUCP (Bill England) (06/17/90)

In article <1990Jun15.020958.594@dynsim2.uucp> vlr@dynsim2.uucp (Vic Rice) writes:
>Has anybody had any success implementing the FAS async driver under
>SCO ODT (UNIX 5.3.2). 
>
>I would really like to get this working, especially since SCO's 
>uugetty is broken. This forces me to muck around with enable/disable
>since I have only one serial port for both incoming and outgoing
>traffic.

   It is?  I've been using uugetty on stephsf for both logins and
   uucp traffic for about 4 months and have had no problems. 

   The functions of 'getty' that are supposed to allow uucp to work 
   are broken or not implemented however, so you must run uugetty 
   to allow logins and uucp. (Equipment 386 20Mhz, DTK with 8Megs )

>
>I have an ALR PowerVEISA w/ 386 and standard 2 port com board
>(Everex Magic I/O). 
>
>Does the SCO sio driver need to be disabled (SCO doesn't have an "asy"
>driver as referenced in the docs) ? If so, how ?

   [ Details Ommited ]

>the usual, an "F1" appears on the left of the screen and its 
>"deep sleep" time.
> 
>Any help would be greatly appreciated.
>-- 
>Dr. Victor L. Rice
>Litwin Process Automation


  This all sounds _very_ interesting.  I was considering trying to 
  get 'The Final Async Solution' running here as well but I was first 
  going to see if the com ports would run at 19.2 without my mucking
  with them.  I'll have a Telebit in a short while and will be able to
  test with that.

  Please continue to post summarys of this work!  I'm very interested
  in the details and will look it over and make suggestions if I'm
  able!


 +--------
 |  Bill England
 |  Stephen Software Systems, Inc.,   Tacoma Wa.
 |  wengland@stephsf.com              +1 206 564 2122
 |
  * *      H -> He +24Mev
 * * * ... Oooo, we're having so much fun making itty bitty suns *
  * *

chip@chinacat.Unicom.COM (Chip Rosenthal) (06/17/90)

>> I waded into the driver a little and found that fasinit() was calling a
>> UART test routine that in turn called delay() [...]
>> I stubbed the test routine out and the driver came up fine.

That test routine is what decides whether or not the UART has a FIFO.  I
don't think you want to chuck it entirely.

I played around with FAS a bit with SCO XENIX, which has the same limitations
of calling delay() in an xxinit() routine.  I just #define'ed delay() to
call a procedure which does a counting loop.  Since the delay is just to
"let the UART settle a bit" after configuring it and before pounding data
through it, the timing is not critical.  However, I didn't feel comfortable
chucking the delay entirely.  Although I didn't contact the author or
experiment around with it, it doesn't seem to be the sort of thing one
adds without a good reason.  The busy loop stuff is definately ugly, but
given that it runs once during initialization time, it isn't that bad a
compromise.

BTW...to forestall the obvious next question, I never fully debugged the
faswrite() routine, so I don't have a FAS for XENIX I can send out.  Sorry.

-- 
Chip Rosenthal                            |  You aren't some icon carved out
chip@chinacat.Unicom.COM                  |  of soap, sent down here to clean
Unicom Systems Development, 512-482-8260  |  up my reputation.  -John Hiatt