Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!mtune!jhc
From: jhc@mtune.UUCP
Newsgroups: unix-pc.general,comp.sys.att
Subject: BREAK on the 3B1
Message-ID: <1166@mtune.ATT.COM>
Date: Wed, 2-Sep-87 23:03:52 EDT
Article-I.D.: mtune.1166
Posted: Wed Sep  2 23:03:52 1987
Date-Received: Sat, 5-Sep-87 02:45:16 EDT
References: <235@amanue.UUCP>
Reply-To: jhc@mtune.UUCP (Jonathan Clark)
Organization: AT&T ISL Middletown NJ USA
Lines: 46
Keywords: 3B1 BREAK tty000 driver eats null
Xref: utgpu junk:5712 comp.sys.att:946
Summary: Yes, there's a bug

Well, I got interested enought to test this myself, complete with my
own set of kernel debugging, and you are right, it isn't responding
'properly' to a BREAK. BTW do you realize that if you boot a kernel
that isn't called /unix then the entire boot procedure falls over
trying to load the window driver, and you get a machine in a very
peculiar state. Anyway.

It's not documented anywhere that I can find, but other tty drivers do two
things when presented with a BREAK with IGNBRK *not* set:

1) generate SIGINT if BRKINT is set
2) pass the character ASCII NUL up to the application. getty then uses
this NUL to switch speeds.

The tty driver on the UNIX PC never does #2.

So far I am holding to the belief that point 2 should not happen if
IGNBRK is set, otherwise the bit is useless, but I'm capable of being
convinced otherwise.

Just for the record, this happens on *all* the RS232 ports, combo or
motherboard, and there is no line of code that I could find in any of
three releases which says 'eat the null'. Neither am I aware of any
such bug report, but then I am not the primary contact in the
development organization.

The quote:

"hundreds of machines are switching speeds happily on any port."

was mine, and I apologize for it, I was wrong. It turns out that the
machines for which I thought this was happening are having uucp sent
to them indirectly via our hosts. For reasons that you don't want to
know about, this avoids the situation.

Anyway, I left a modified kernel building on my own machine this
evening, and I will play with this some more. I can fix the problem,
I think, but I'm not sure that I can make this into a loadable driver.
Neither do I have any idea how to get any such fix out to the rest of
the world. If I get enthusiastic and lucky I might be able to post an
adb patch...
-- 
Jonathan Clark
[NAC,attmail]!mtune!jhc

An Englishman never enjoys himself except for some noble purpose.