meyer@mimsy.UUCP (John R. Meyer) (07/06/87)
I am having problems with the cu command under SCO XENIX-286 2.1.0. Everything goes along fine until I terminate the session with the "~." command. Every so often, the program crashes with the message "Segmentation violation -- core dumped" and the terminal hangs. Has anyone else had this problem? Know how to fix it? Thanks in advance, John -- John R. Meyer Domain: meyer@mimsy.umd.edu 10208C Ashbrooke Ct. Path: seismo!mimsy!meyer Oakton, VA 22124 Phone: (703) 644-3944 (O) Disclaimer: The views expressed are my own. (703) 281-5157 (H)
chkg@ptsfa.UUCP (Chuck Gentry) (07/07/87)
I had the same problem under 2.1.0. It would even dump me in the middle
of a session. The problem seemed to occur without a pattern.
XENIX SysV R2.2.1 does not seem to have the 'cu' problem. (I've been
using it for about a month and the problem has never occured.) It also
has some very nice enhancements that are worth the time and money for
the upgrade.
Chuck Gentry
{lll-lcc,seismo,qantel}!ptsfa!chkgmichael@macom1.UUCP (Michael Mullins) (07/07/87)
in article <7341@mimsy.UUCP>, meyer@mimsy.UUCP (John R. Meyer) says: > > I am having problems with the cu command under SCO XENIX-286 2.1.0. > Everything goes along fine until I terminate the session with the > "~." command. Every so often, the program crashes with the message > "Segmentation violation -- core dumped" and the terminal hangs. > > Has anyone else had this problem? Know how to fix it? I have seen this error on several versions of xenix. Not just on the At clone stuff, but also on a specific version from intel on one of their multiuser boxes. I assume when you say the terminal hangs, that it apears that you can' not do anything? Usually, if you press line-feed, or ^J, it will flush the input buffer, give you some message about "not found...." then all you have to do is "exit^J" which will log you out, without having to kill the process from another port. Another thing you can try, which clear strange terminal gyrations under Sys V, is to enter: "stty sane^J" I have done this second fix on 2.1.3, and work fine for me... Like John says above, the upgrade to 2.2 is worth it. Not only is the CU fixed, but also drivers for many of the popular tape archive devices are included. john mullins -- Dennis Paul Roth CENTEL Business Information Systems, Inc. 5515 Security Lane, Rockville, Maryland, 20852, (301) 984-3636 UUCP: roth@macom1.UUCP or decuac!macom1!roth
hill@nicmad.UUCP (07/07/87)
I have seen the same problem back when I was running SCO Xenix 2.1.3. You can unlock the terminal by going to another terminal and commanding that port to sane (ie. stty </dev/tty1a sane). I never found a way to avoid the problem. I haven't tested it with 2.2.1, because I started using kermit in place of it for my dial outs and don't have any problems with that. The kermit I'm running does everything "cu" does plus binary file transfer. Ray Hill uwvax!nicmad!hill
ericg@sco.UUCP (Eric Griswold) (07/09/87)
In article <1747@nicmad.UUCP> hill@nicmad.UUCP (Ray Hill) writes: > >I have seen the same problem back when I was running SCO Xenix 2.1.3. > > Ray Hill The problem is indeed fixed under 2.2.1 -- Eric Griswold Quote: 3 more of these will make a gallon Path: {decvax!microsoft, ihnp4, ucbvax!ucscc}!sco!ericg Disclaimer: It's all my fault, SCO had NOTHING to do with it.