Xref: utzoo comp.sys.att:3901 unix-pc.uucp:52 unix-pc.general:1195
Path: utzoo!attcan!uunet!labrea!rutgers!mailrus!uwmcsd1!nic.MR.NET!umn-cs!bungia!sialis!rjg
From: rjg@sialis.mn.org (Robert J. Granvin)
Newsgroups: comp.sys.att,unix-pc.uucp,unix-pc.general
Subject: Re: tty000 'n' uucico (ph0 TCSBRK kills tty000)
Keywords: unixpc phone driver bug break tty000
Message-ID: <706@sialis.mn.org>
Date: 2 Aug 88 23:37:14 GMT
References: <14@sialis.Sialis.MN.ORG> <4390@cbmvax.UUCP>
Reply-To: rjg@sialis.mn.org (Robert J. Granvin)
Organization: Dr. Ho Laboratory and Day Care Center
Lines: 49

>In article <14@sialis.Sialis.MN.ORG> rjg@sialis.mn.org (Robert J. Granvin) writes:

Wow!  This is an OLD (meaning nearly a year) message.  Where did it
resurface?

Anyways, since it usually needs to be hashed out every once in a while
anyways...

>>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).
>
>> [...]
>
>If you think it will help, I'll call the hotline and complain.

No need to.

This problem is a bug in various drivers on the Unix PC.  The problem
existed under OS 3.5.  What I can't recall clearly anymore is whether
3.51 fixed it.  I don't believe so.  However, installing the 3.51
fixdisks (3.51a kernel) will solve this problem (if not solved by
3.51) as well as a few