Xref: utzoo comp.sys.att:3945 unix-pc.uucp:56 unix-pc.general:1229 Path: utzoo!edhnic!becker!ziebmef!ncrcan!lsuc!attcan!uunet!cbmvax!ditto From: ditto@cbmvax.UUCP (Michael Ditto) Newsgroups: comp.sys.att,unix-pc.uucp,unix-pc.general Subject: Re: tty000 'n' uucico (ph0 TCSBRK kills tty000) Summary: Same here Keywords: unixpc phone driver bug break tty000 Message-ID: <4390@cbmvax.UUCP> Date: 1 Aug 88 20:11:01 GMT References: <14@sialis.Sialis.MN.ORG> Reply-To: ford@kenobi.cts.com (Michael Ditto) Organization: Commodore Technology, West Chester, PA Lines: 34 In article <14@sialis.Sialis.MN.ORG> rjg@sialis.mn.org (Robert J. Granvin) writes: >The instant you send the BREAK, [ to the OBM ] > tty000 goes out to lunch. All output to >the device is buffered, and not sent, and input is not accepted from >the terminal. If you don't send a BREAK, the terminal remains >(apparently) unaffected. > >The remote terminal will 'return to life' when the call is complete >and uucico starts up _another_ call. I have seen this; it's quite easily reproducable. In particular, I often log in via tty000 and "cu" out via ph0. If I type ~%break to cu, my terminal (on tty000) freezes (no input or output). A bit of experimenting revealed that SETTING the stty settings of ph0 will cause tty000 to return to life (i.e., going to the console and running "stty 1200 < /dev/ph0" makes everything work again). I don't think I knew about the bug when I was covered by warranty, and my current solution is just to avoid typing ~%break. >I can't believe that no one else out there has run across this, and I >find it hard to believe that AT&T has no knowledge of it (even though >the person(s) on the phone may not have, though). If you think it will help, I'll call the hotline and complain. -- -=] Ford [=- . . (In Real Life: Mike Ditto) . : , ford@kenobi.cts.com This space under construction, ...!ucsd!elgar!ford pardon our dust. ditto@cbmvax.commodore.com