tron1@tronsbox.UUCP (HIM) (10/10/89)
Well, I am about ready to give up on ISC 2.0.2 .
If there is anyone who has managed to get a GOOD asy device running from any
source, I could really use the help.
Our saga so far.
1) The origional ISC 2.0.x driver.....
Well. It doesnt REALLY work well. Many mysterious happenings.
Problems with port sharing. Character loss problems.
2) MAXPEED SS8 Inteligent I/O card...
The hardware is good, but the driver is not so useful. It works GREAT
for terminals. But can't control a modem for its life really.
Bugs characterized by :
I. Hung uucico's
II. The persistant belief that the port is "Device Busy" when it is
not opened in any way . Turning the modem off/on will fix.
III. The port will OFTEN refuse to send data OUT (sd).
This is most harmefull when you are logged in directly
incomming data is correctly acted upon, but character echo is
lost. I HAVE SEEN this from the host end while on the phone
voice with the person logged in. The (sd) light is NOT going on.
If the user does a "ls -ls" , the hard drive runs, the command
executes, but the result is not transmitted. This bug can be
cleared in two ways. One is , as root , do a "> /dev/ttyax" where
the device name is the stuck one. Two, wait about 3 minutes and
the data will be transmitted.
This is too bad. It is a nice board, but almost useless due to these
bugs.
3) The Interactive Systems X5 "Asy Update".
I'll spare you the pain. It hasn't worked so far. It installs, but wont
perform right . Getty's hang and won't "kill -9". Ports will drop
characters at will.
SO IF ANYONE HAS A WORKING ASY DRIVER -- HELP!!!
****************************************************************************
So Lord, I'd think you more than wise, (and me much less a jerk)
if only once you might supply.....
SOME PENGUIN WINGS THAT WORK!" Opus
>>>>> OPUS IS ALIVE AND WELL IN OUTLAND <<<<<
UUCP: tron1@tronsbox.UUCP BEST PATH ---> uunet!tronsbox!tron1
Sysop, The Penthouse ]I[ BBS - (201)759-8450 / (201)759-8568
****************************************************************************akcs.larry@nstar.UUCP (Larry Snyder) (10/10/89)
>Well, I am about ready to give up on ISC 2.0.2 . >If there is anyone who has managed to get a GOOD asy device running from any >source, I could really use the help. Well - I assume you didn't install the X5 kernel configuration guide which will solve most if not all of your problems.
cpcahil@virtech.UUCP (Conor P. Cahill) (10/11/89)
In article <[2531618a:210]comp.unix.i386@tronsbox.UUCP>, tron1@tronsbox.UUCP (HIM) writes: > 1) The origional ISC 2.0.x driver..... > Well. It doesnt REALLY work well. Many mysterious happenings. > Problems with port sharing. Character loss problems. > > 2) MAXPEED SS8 Inteligent I/O card... > The hardware is good, but the driver is not so useful. It works GREAT > for terminals. But can't control a modem for its life really. My Maxspeed also has problems under 386/ix, but they differ from yours. > Bugs characterized by : > > I. Hung uucico's I have never had a hung uucico on my system (that I noticed). > II. The persistant belief that the port is "Device Busy" when it is > not opened in any way . Turning the modem off/on will fix. This I have run into, but only when I was using cu to talk to the modem. It never happened with uucico, maybe just luck. I have noticed that the driver does not always drop DTR when I disconnect from the modem, but this hasn't given me too much problems (other than a large phone bill if I didn't notice it). > III. The port will OFTEN refuse to send data OUT (sd). > This is most harmefull when you are logged in directly > incomming data is correctly acted upon, but character echo is > lost. I HAVE SEEN this from the host end while on the phone > voice with the person logged in. The (sd) light is NOT going on. I have seen this problem with my printer. If I send two jobs to the printar in succession (and the second job gets queued before the first job is complete), the second job will lock up the port. This is fixed with the "> /dev/tt..." that you mentioned later, or by disabling and reenabling the port. > If the user does a "ls -ls" , the hard drive runs, the command > executes, but the result is not transmitted. This bug can be > cleared in two ways. One is , as root , do a "> /dev/ttyax" where > the device name is the stuck one. Two, wait about 3 minutes and > the data will be transmitted. The big problem that I have had is that the board does not seem to support incomming data at 19200 (from a T2500). When I upped the speed from 9600 I got spurious input data queued in the tty port for a different tty and lost the data from the correct port. My uucico throughput at 9600 baud is around 850 cps, while it is only 300 cps at 19200. I have called maxspeed and so far they have not been able to help me. Good luck... -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
jgd@rsiatl.UUCP (John G. De Armond) (10/11/89)
In article <[2531618a:210]comp.unix.i386@tronsbox.UUCP> tron1@tronsbox.UUCP (HIM) writes: > > >Well, I am about ready to give up on ISC 2.0.2 . > This would be funny if we had gotten this trash public domain. (No smileys). >If there is anyone who has managed to get a GOOD asy device running from any >source, I could really use the help. NO!!!! but I have a workaround. My current configuration is 2.0.2 with the x5 upgrade. You need that upgrade for what follows. As delivered, the system is incapable of keeping up with a 9600 baud Telebit line, something my XT turbo machines will do with ease!! I tried the pd asy driver mentioned here in the group but it is flakey, hanging on ioctl calls and is generally unstable. I do plan to work on that a bit in the future. You MUST install 16550 uarts in order to run over 4800 baud on a non-cached machine. Mine is a 20 mhz non-cached, no wait state machine. With the 16550s installed and the X5 upgrade, speed is no problem. It easily handles the telebit even with a couple of compiles going in the foreground. >Our saga so far. > >1) The origional ISC 2.0.x driver..... > Well. It doesnt REALLY work well. Many mysterious happenings. > Problems with port sharing. Character loss problems. Yes, biggest problem is spurrious signals. >3) The Interactive Systems X5 "Asy Update". > I'll spare you the pain. It hasn't worked so far. It installs, but wont > perform right . Getty's hang and won't "kill -9". Ports will drop > characters at will. It still generates spurrious signals, just not so many. uugetty is brain-dead. One note, if you try to make uugetty run, be sure and use the one in /usr/lib/uucp, NOT the one in /etc. The /etc/getty is totally broken. Other problems you have not mentioned. uugetty does not respect lock files. I've seen it get in such a nice conversation with another login that it locks all keyboard input, which means Big Red Switch time. There are a couple of things you can do to make uugetty at least run. in /etc/gettydefs, place the statements CLOCAL and BRKINT in the first stanza and BRKINT in the second. CLOCAL will make the modem-controled device (minor device 1) work somewhat properly. BRKINT makes the DTR line drop after the last process dies (sometimes, at least). Also, be sure and turn CLOCAL on during modem chatting and back off after connection is established. This involves the \M and \m (off and on respectively) in Dialers. And be sure to use the "tty01,M" notation in Devices. A workaround I came up with for the failure to observe lock files (don't gag now) got me by while I worked on the uutty replacement. What I did was write a script that encapsulates uucico. It copies an /etc/inittab in place that turns the getty off, then it kills the getty. Finally, it runs the uucico binary. When uucico exits, it replaces the /etc/inittab and respawns the gettys. Since uusched expects to run a binary, I had to write a 3 line c program that exec's a shell and runs the script. Yes, it's grody but it works. I solved the problems the old fashioned way - I wrote my own uugetty. I based it in the pd uutty written by John Chambers. The version I got was written to control some strange VME smart card via a firmware debugger. And it was broken. I've rewritten most of it but am not yet finished. Among the things it does are the following: Traps ALL signals. Sig 9 is of course, fatal so the process can be killed. Generates an activity log and records all spurrious signals Ignores /etc/gettydefs. Too much trouble. Takes an intelligent look at data comming in to figure out if it is in conversation with another login. IF so, it shuts up until prodded by a single <CR> on a line. Waits for a <CR> to fire a login: prompt. Respects lock files (!!!!!!!) Creates a proper lock file for uucico. Exits properly when the line hangs up and toggles DTR which is necessary to force the telebit to reload default params. Works with either a blocking or non-blocking asy driver. (!!!) Is fairly small. Aborts the login process if it receives any illegal login name characters. A ":" would probably mean that it was chatting with another login. Other spurrious characters could mean line noise or hackers. Major problems at this point: Ioctl parameters are hard-coded. They may stay this way as it is as easy for me to change defines in a .h file as it is to get /etc/gettydefs right. A password is required. I don't personally like passwords on uucp accounts so this is a priority. Debugging log is cryptic at best. Much work to be done here. I plan on posting this work to the net when I get it finished. PLEASE don't hit me with a bunch of requests for the work in progress. It may take me a week to finish, if the %&^%^& system will stay up long enough. The work-arounds above got me by while I was working on this problem. Boy, I hope one day that Interactive will get it together. It would be nice to offer this stuff to customers with some hope it would work. As it is, OS/2 is looking (ahem) better every day. (now I'll go wash my mouth out!). John >SO IF ANYONE HAS A WORKING ASY DRIVER -- HELP!!! > I am going to get back to work on the pd ASY driver as soon as I get time. John -- John De Armond, WD4OQC | Manual? ... What manual ?!? Radiation Systems, Inc. Atlanta, GA | This is Unix, My son, You gatech!stiatl!rsiatl!jgd **I am the NRA** | just GOTTA Know!!!
merlin@mic.UUCP (Merlin Wilkerson) (10/11/89)
In article <[2531d5ce:22.1]comp.unix.i386;1@nstar.UUCP> akcs.larry@nstar.UUCP (Larry Snyder) writes: >>Well, I am about ready to give up on ISC 2.0.2 . >>If there is anyone who has managed to get a GOOD asy device running from any >>source, I could really use the help. > >Well - I assume you didn't install the X5 kernel configuration guide which >will solve most if not all of your problems. WELL, you know what happens when you ASSume. I *have* installed the "X5 kernel upgrade". It solved exactly zero problems. (other than help me discover the kernel rebuild bug in kconfig). I followed the docs and had my hopes up. I put a getty on the line and recieved a call. I dialed out with cu with no problem. "Allright", I exclaimed. However, when I disconnected, the RD and SD lights were blinking rapidly and the getty process had become immortal. Subsequent calls to cu gave "CAN'T ACCESS DEVICE" errors. Resets and retest yielded the same results. I would really like a bi-direction modem to work. After several weeks of "going to ship the fix next week" responses form ix tech, and then it doesn't work, I can understand being ready to give up. I just can't believe that ix doesn't think this is a big deal. Evidently they want serial board manufacturers to solve this problem for them. Then they can just stiff-arm the poor fools that think it should work. Flame me all you want, but it shouldn't take an EE, a C expert, a UNIX guru, and an act of GOD to get bidirection working on a standard serial port. thanks, merlin
izen@amelia.nas.nasa.gov (Steven H. Izen) (10/11/89)
In article <[2531618a:210]comp.unix.i386@tronsbox.UUCP> tron1@tronsbox.UUCP (HIM) writes: >Well, I am about ready to give up on ISC 2.0.2 . > perform right . Getty's hang and won't "kill -9". Ports will drop > characters at will. I'm using X5 with two 2400 baud modems, one bidirectionally. I regularly use uucico, cu and kermit and have had no problems. For me it works as advertised. What configuration was giving you problems? Were you using TB modems? Are you sure that the hardware is o.k.? Interrupts set correctly? -- Steve Izen: {sun,uunet}!cwjcc!skybridge!izen386!steve or steve%izen386.uucp@skybridge.scl.cwru.edu or izen@cwru.cwru.edu "My second bike is a car."
izen@amelia.nas.nasa.gov (Steven H. Izen) (10/12/89)
In article <290@mic.UUCP> merlin@mic.UUCP (Merlin Wilkerson) writes: > I followed the docs and had my hopes up. I put a getty on the >line and recieved a call. I dialed out with cu with no problem. >"Allright", I exclaimed. However, when I disconnected, the RD and SD >lights were blinking rapidly and the getty process had become >immortal. Subsequent calls to cu gave "CAN'T ACCESS DEVICE" errors. It sounds to me like your modem isn't set properly. I may be wrong, (I often am), but if your modem is either 1) not in quiet mode (ATQ[01] toggles that) or 2) not resetting properly on disconnect, you would get those symptoms. You want to set the default state to quiet, and then have the first command to the modem in the Devices string be the appropriate ATQ to turn quiet off. You also need to make sure that the modem resets to quiet state on loss of carrier detect. the command to do that is AT&D[0123] (I don't have my manual in front of me so I don't remember which of [0123] actually does it.) OF course, the above assumes that your modem is Hayes compatible. If it isn't, maybe someone else can help. Other possibilities which would explain that behavior include having uucp or getty use the wrong device names- getty wants ttyd0, and cu and uucico wants acu0 (or whatever number). But since you have RTFM those should be set up o.k. I recently added the X5 config update, and I followed the directions carefully and have had no trouble getting a 2400 baud bidirectional port working, so at least there is one point on the board for ISC here :-). Actually, I'll give them only 1/2 point because I had to call them three times before they'd FAX me the docs which weren't included with my disk. -- Steve Izen: {sun,uunet}!cwjcc!skybridge!izen386!steve or steve%izen386.uucp@skybridge.scl.cwru.edu or izen@cwru.cwru.edu "My second bike is a car."
pim@cti-software.nl (Pim Zandbergen) (10/12/89)
jgd@rsiatl.UUCP (John G. De Armond) writes: >Other problems you have not mentioned. uugetty does not respect lock files. >I've seen it get in such a nice conversation with another login that >it locks all keyboard input, which means Big Red Switch time. At first I had the same problem with uugetty. This was because of a mistake in /etc/inittab: A3:234:respawn:/usr/lib/uucp/uugetty -r -t 60 /dev/ttyA3 19200 I changed this to: A3:234:respawn:/usr/lib/uucp/uugetty -r -t 60 ttyA3 19200 and everything works fine. -- Pim Zandbergen internet : pim@cti-software.nl CTI Software BV uucp : ..!uunet!ctisbv!pim Laan Copes van Cattenburch 70 phone : +31 70 542302 2585 GD The Hague, The Netherlands fax : +31 70 512837
haugen@bulus3.BMA.COM (John M. Haugen) (10/12/89)
In article <[2531618a:210]comp.unix.i386@tronsbox.UUCP>, tron1@tronsbox.UUCP (HIM) writes: > > > Well, I am about ready to give up on ISC 2.0.2 . > > If there is anyone who has managed to get a GOOD asy device running from any > source, I could really use the help. > I my case, I was able to get the X5 update to work. I am running a 20 Mhz 386 Micro Channel machine with a Telebit Tralblazer Plus plugged into the serial port. This machine uses a 16550 UART so the FIFO gets used. I now have the modem set to 19200 and see effective transfer rates of 1100 chars/sec on occasion. I have not seen any problems with spurious signals. Incoming doesn't seem to be having any problems either though that has not been tested as thoroughly. I am using acu0 for outgoing, ttyd0 for incoming and am using getty, not uugetty for incoming. At least someone isn't flaming ISC for this update. John M. Haugen Domain: haugen@BMA.COM Bull Micral of America UUCP: ...!uunet!bulus3!haugen 1970 Oakcrest Ave. #300 ATT: 612-633-5660 St. Paul, MN 55113-2624
dkelly@npiatl.UUCP (Dwight Kelly) (10/14/89)
In article <290@mic.UUCP> merlin@mic.UUCP (Merlin Wilkerson) writes: > >"Allright", I exclaimed. However, when I disconnected, the RD and SD >lights were blinking rapidly and the getty process had become >immortal. Subsequent calls to cu gave "CAN'T ACCESS DEVICE" errors. >Resets and retest yielded the same results. I have installed 2.0.2 with the X5 upgrade and a 16550 chip on a 20mhz non-cached machine with a bi-directional TB running at 19200 with NO problems! I have even run X with motif, a tape backup, a floppy copying, and not one signal. The rapidly blinking lights sounds like you have the response codes ON for the TB. Make sure that you using TB19200 gettydefs with ALL the register setting Interactive lists in the X5 upgrade sheets. If you need help, call me or email and I will trying to identify the problem. Dwight Kelly Director R&D Network Publications, Inc. dkelly@npiatl (404) 962-7220