jca@pnet01.cts.com (John C. Archambeau) (02/08/91)
I'm having a problem with FAS 2.08. The problem I am having is
getting it to work with both my standard COM1 and COM2 ports and my
AST FourPort card. I can use either one card or the other, but if I
have both of them in my system, there's a problem.
If I use my original AT I/O card, I get an unkillable process when I
try to do a cu to COM1. I can not do a ~. to get out of cu. Everything
works ok with my AST card both with cu and under VP/ix.
Under the I/O card that I've upgraded to (two serial, one parallel, IDE,
and an FDC), the system doesn't even get that far. The system reboots
constantly.
Both I/O cards worked under FAS 2.07, only thing I could not do is
access the ports under VP/ix. I can do that now, but I have to have
either the AST board or the I/O card in system, but not both. I am
using the canned space.c which is named space-ast4c12 in the FAS 2.08
distribution.
Any help would be appreciated.
Thanks,
// JCA
/*
**--------------------------------------------------------------------------*
** Flames : /dev/null | What to buy?
** ARPANET : crash!pnet01!jca@nosc.mil | EISA or MCA?
** INTERNET: jca@pnet01.cts.com | When will the bus wars end?
** UUCP : {nosc ucsd hplabs!hp-sdd}!crash!pnet01!jca
**--------------------------------------------------------------------------*
*/gil@limbic.ssdl.com (Gil Kloepfer Jr.) (02/09/91)
In article <7457@crash.cts.com> jca@pnet01.cts.com (John C. Archambeau) writes: >I'm having a problem with FAS 2.08. The problem I am having is >getting it to work with both my standard COM1 and COM2 ports and my >AST FourPort card. I can use either one card or the other, but if I >have both of them in my system, there's a problem. > >If I use my original AT I/O card, I get an unkillable process when I >try to do a cu to COM1. I can not do a ~. to get out of cu. Everything >works ok with my AST card both with cu and under VP/ix. It took me a little longer this time, but I did get FAS 2.08 running, and it seems to be working fine with the standard com1/com2 and Steve Nuchia's 4-port card. When I finally got everything configured, I found a nasty problem with my cabling -- I had the hardware flow control lines (RTS/CTS) straight- through instead of swapped (between 2 machines). You might want to check that out. In the initialization, it almost appears that flow control depends on DSR, which isn't available on Steve's board. I removed the reference to DSR from the flow control variable. Finally, be REALLY CAREFUL not to start gettys on ports that are disconnected. I've had several system crashes that I can't pin-down, but happened since installing FAS 2.08. I think it's probably wise to obey Uwe's warning about this. -- Gil Kloepfer, Jr. gil@limbic.ssdl.com ...!ames!limbic!gil Southwest Systems Development Labs (Div of ICUS) Houston, Texas "There are beautiful people I wish would have never opened their mouths, because such ugliness oozes out." Philosophy Prof. at NYIT
jca@pnet01.cts.com (John C. Archambeau) (02/11/91)
gil@limbic.ssdl.com (Gil Kloepfer Jr.) writes: >In article <7457@crash.cts.com> jca@pnet01.cts.com (John C. Archambeau) writes: >>I'm having a problem with FAS 2.08. The problem I am having is >>getting it to work with both my standard COM1 and COM2 ports and my >>AST FourPort card. I can use either one card or the other, but if I >>have both of them in my system, there's a problem. >> >>If I use my original AT I/O card, I get an unkillable process when I >>try to do a cu to COM1. I can not do a ~. to get out of cu. Everything >>works ok with my AST card both with cu and under VP/ix. > >It took me a little longer this time, but I did get FAS 2.08 running, >and it seems to be working fine with the standard com1/com2 and Steve >Nuchia's 4-port card. > >When I finally got everything configured, I found a nasty problem with >my cabling -- I had the hardware flow control lines (RTS/CTS) straight- >through instead of swapped (between 2 machines). You might want to >check that out. I managed to fix the problem with it. If I move the AST FourPort off of IRQ 2 (9), it works just fine either in or out of VP/ix. I do not have any devices that are using IRQ 2 (9) in my system. Question I have is what could possibly be causing my problems with using IRQ 2 (9) with my AST FourPort card? // JCA /* **--------------------------------------------------------------------------* ** Flames : /dev/null | What to buy? ** ARPANET : crash!pnet01!jca@nosc.mil | EISA or MCA? ** INTERNET: jca@pnet01.cts.com | When will the bus wars end? ** UUCP : {nosc ucsd hplabs!hp-sdd}!crash!pnet01!jca **--------------------------------------------------------------------------* */
bill@unixland.uucp (Bill Heiser) (04/23/91)
After installing fas2.08 on Esix, I have had the following problems:
1. When a calling party logs out, carrier doesn't drop; instead, a new
login prompt comes up. I found that -hupcl is set, instead of hupcl.
Manually setting it causes carrier to drop (properly) at logout. Why
did this change with the fas installation (I was using asy before), and
how should I fix it?
2. I can still connect with two of my uucp sites -- but one doesn't let
me login any more. I get a login prompt, send my username, then get
the login banner again, followed by "enough already." It seem slike
maybe a flow control problem? why does it work with the other sites?
Thanks in advance,
Bill
p.s. The modems are Practical Periphs 2400, USR HST (OLD), and Telebit
Trailblazer. The uucp dialing is done with the Telebit.
--
bill@unixland.uucp The Think_Tank BBS & Public Access Unix
...!uunet!think!unixland!bill
...!{uunet,bloom-beacon,esegue}!world!unixland!bill
508-655-3848 (2400) 508-651-8723 (9600-HST) 508-651-8733 (9600-PEP-V32)gemini@geminix.in-berlin.de (Uwe Doering) (04/24/91)
bill@unixland.uucp (Bill Heiser) writes: >After installing fas2.08 on Esix, I have had the following problems: > >1. When a calling party logs out, carrier doesn't drop; instead, a new >login prompt comes up. I found that -hupcl is set, instead of hupcl. >Manually setting it causes carrier to drop (properly) at logout. Why >did this change with the fas installation (I was using asy before), and >how should I fix it? The fasopen() function calls the generic kernel function ttinit() on first open of the port. This function is responsible for setting up the flags in the tty structure (B300, CS8, CREAD, HUPCL, in this case). I just checked it on my system, and it works this way. So either the ttinit() function in ESIX is broken, and was "fixed" by their asy driver, or this asy driver always enabled HUPCL, regardless of what state it would be set to by the ioctl() TCSETA* call. In both cases you need to find a way to enable the HUPCL flag on login. Did you check the /etc/gettydefs file? Is the HUPCL flag contained in the line you use for that port? If not, add it. >2. I can still connect with two of my uucp sites -- but one doesn't let >me login any more. I get a login prompt, send my username, then get >the login banner again, followed by "enough already." It seem slike >maybe a flow control problem? why does it work with the other sites? I'm not sure, but I heard of uucicos that don't like long login banners and give up if there is no Shere=<sitename> message contained in a certain number of characters. That would also explain why this only happens with one of the UUCP sites. The other two may have shorter banners. Short from replacing uucico, I don't know how to fix this. Uwe -- Uwe Doering | INET : gemini@geminix.in-berlin.de Berlin |---------------------------------------------------------------- Germany | UUCP : ...!unido!fub!geminix.in-berlin.de!gemini
rcd@ico.isc.com (Dick Dunn) (04/25/91)
gemini@geminix.in-berlin.de (Uwe Doering) writes: [problem, looks like too-long banner] > I'm not sure, but I heard of uucicos that don't like long login banners > and give up if there is no Shere=<sitename> message contained in a certain > number of characters. That would also explain why this only happens > with one of the UUCP sites... The way I read the problem description, it wasn't clear whether the babble was during the login sequence (the initial herald) or after login when uucico is getting going (Uwe's speculation). If it is the latter, there's one long shot: On BSDish systems, and some others, you can shut off most of the post-login babble by putting a file named ".hushlogin" in the home directory. That would be something you'd have to request of the remote site. -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...While you were reading this, Motif grew by another kilobyte.
bill@unixland.uucp (Bill Heiser) (04/25/91)
In article <JX0P3KO@geminix.in-berlin.de> gemini@geminix.in-berlin.de (Uwe Doering) writes: >bill@unixland.uucp (Bill Heiser) writes: > >In both cases you need to find a way to enable the HUPCL flag on >login. Did you check the /etc/gettydefs file? Is the HUPCL flag >contained in the line you use for that port? If not, add it. This is the gettydefs entry (2400 used as sample) 2400H# B2400 # B2400 CS8 CSTOPB HUCPL BRKINT ICRNL ISIG ICANON ECHO ECHOK OPOST ONLCR #((2400)To use Bulletin Board type "bbs")\r\nlogin: #1200H >I'm not sure, but I heard of uucicos that don't like long login banners >and give up if there is no Shere=<sitename> message contained in a certain >number of characters. That would also explain why this only happens >with one of the UUCP sites. The other two may have shorter banners. Short >from replacing uucico, I don't know how to fix this. I got it to work by fiddling with the login script. It was interesting thta it was only this one site, and only after installing FAS that I had this problem! Actually, when I had previously tried to use flow control the same thing had happened. Very strange. Now to get the transfer rates up to normal again. Bill -- bill@unixland.uucp The Think_Tank BBS & Public Access Unix ...!uunet!think!unixland!bill ...!{uunet,bloom-beacon,esegue}!world!unixland!bill 508-655-3848 (2400) 508-651-8723 (9600-HST) 508-651-8733 (9600-PEP-V32)
witr@rwwa.COM (Robert Withrow) (04/25/91)
In article <JX0P3KO@geminix.in-berlin.de> gemini@geminix.in-berlin.de (Uwe Doering) writes: |I'm not sure, but I heard of uucicos that don't like long login banners |and give up if there is no Shere=<sitename> message contained in a certain |number of characters. That would also explain why this only happens |with one of the UUCP sites. The other two may have shorter banners. Short |from replacing uucico, I don't know how to fix this. A good bet. Try doing a Uutry on that site and see if uucico says ``enough already'' or something equivalent when executing your chat script. If so complain to that site's postmaster. -- --- Robert Withrow, R.W. Withrow Associates, Swampscott MA 01907 USA Tel: +1 617 598 4480, Fax: +1 617 598 4430, Net: witr@rwwa.COM
jde@everex.uucp (-Jeff Ellis()) (04/27/91)
In article <JX0P3KO@geminix.in-berlin.de> gemini@geminix.in-berlin.de (Uwe Doering) writes: >bill@unixland.uucp (Bill Heiser) writes: > >>After installing fas2.08 on Esix, I have had the following problems: >> >>1. When a calling party logs out, carrier doesn't drop; instead, a new >>login prompt comes up. I found that -hupcl is set, instead of hupcl. >>Manually setting it causes carrier to drop (properly) at logout. Why >>did this change with the fas installation (I was using asy before), and >>how should I fix it? > >The fasopen() function calls the generic kernel function ttinit() on >first open of the port. This function is responsible for setting >up the flags in the tty structure (B300, CS8, CREAD, HUPCL, in this >case). I just checked it on my system, and it works this way. > >So either the ttinit() function in ESIX is broken, and was "fixed" >by their asy driver, or this asy driver always enabled HUPCL, regardless >of what state it would be set to by the ioctl() TCSETA* call. > >In both cases you need to find a way to enable the HUPCL flag on >login. Did you check the /etc/gettydefs file? Is the HUPCL flag >contained in the line you use for that port? If not, add it. We are using FAS 2.08 (and used 2.07 in the past) and have never had any problems like this with our two telebits modems. I do have a custom gettydef entry for 8 bit logins with HUPCL on the line. This driver works very good for us here and on my machine at home. -- Jeff Ellis ESIX SYSTEM/V UUCP:uunet!zardoz!everex!jde US Mail: 1923 St. Andrew Place, Santa Ana, CA 92705