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