ditto@cbmvax.UUCP (Michael Ditto) (08/02/88)
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
rjg@sialis.mn.org (Robert J. Granvin) (08/03/88)
>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