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