jr@amanue.UUCP (08/28/87)
Recently I posted a message concerning a problem I and several other people
were having getting a getty on tty000 to respond to a break. My first thought
was to try to deal with it myself, then talk to people I knew, then come
here. Almost as a whim I called the Hotline with the problem. Boy am I glad
I did! I can now report that there is unequivocally a bug in the tty000
driver -- but the driver for expansion ports is healthy. I spoke to Jim
Lynch at the Hotline on Friday, I think, and he said he'd get back to me.
We finally connected again a couple of days ago, and he reports the following.
(1) He can replicate the problem. He wrote a program that reads from the
port and shows him what it's getting. The hardware *is* detecting a break.
With BRKINT set he found he was clearly getting a signal from the driver, so
the problem was not the hardware. But with BRKINT off the break was producing
*nothing*. getty does nothing fancy to change speed. It appears that all it
is looking for is a null. It just happens that a break, being 100 ms. of all
0-bits, including start and stop bits, should be read by a receiver at any
speed as nulls -- presumably with framing errors. With BRKINT off and IGNBRK
off the null *should* be passed back to the reading process as an ordinary
garden variety null.
(2) He went to the source code for the tty000. Sure enough, HE FOUND THE
OFFENDING LINE OF CODE. In fact, he told me it even has a comment that says
"Eat the null" !!!
So he has reported it through channels in AT&T. He assured me that his group
has no authority to fix bugs, and that there was a possibility that was put
there to fix some other problem, but that hopefully it should be fixed.
Now this leaves the question of how all these "hundreds of machines are
switching speeds happily on any port." I played with this a bit myself, and
it's my opinion that those machines switching speed on tty000 are doing so
not "happily" but luckily. It appears to be a bankable probability that if
a sender is talking at 1200 and sends \r, and a receiver is listening at
2400, the receiver will get 0x80. (Actually it will tend to hear two
characters, one of which is 0x80.) Now if you are telling getty to strip
off the parity bit, woila, the 0x80 becomes a null, and getty dutifully
changes speed. A return at 1200 is enough to get a 2400 baud answerer to
toggle. So far I know of no way to go the other way. If someone is managing
to toggle *FROM* 1200 *TO* 2400 on tty000 I'd sure like to know how.
So it appears that the temporary workaround is to always start at 2400, not
1200. This isn't a very nice solution, though, & I sure hope the driver can
be fixed, because of the following potential problem. If getty is starting
off at 2400 and a caller calls *at 2400*, but in making the connect, line
noise just happens to come across as a null, the 3B1 will unhappily change
speed, and I can't imagine how an L.sys entry could recover and bring it back
to 2400. Perhaps some weird combination of bytes sent at 2400 will also
more or less reliably send a null at 1200, but I'd rather not stay up nights
trying to find such a strange thing.
One more point. I think people should not "cavil" over PC terminal emulators
without being familiar with the specific program in question. Yes, the PeeCee
is brain damaged in many respects -- as a long-time user of such equipment I
will be the first to admit this -- but it does have a real live down-home UART,
it *is* capable of sending a true break if the software is written properly,
and yes, Virginia, there are PC terminal emulators that are written properly,
including at least one by someone who has UNIX experience going back at least
to Version 6, is on the net, knows what L.sys entries and getty are all about
and why true break is important.
Now here's hoping they'll fix this bug, and we can all get an update!
--
Jim Rosenberg
CIS: 71515,124 decvax!idis! \
WELL: jer allegra! ---- pitt!amanue!jr
BIX: jrosenberg seismo!cmcl2!cadre! /jr@amanue.UUCP (08/28/87)
In article <235@amanue.UUCP>, jr@amanue.UUCP (Jim Rosenberg) writes: > (2) He went to the source code for the tty000. Sure enough, HE FOUND THE ^^^^^^^^^^^ > OFFENDING LINE OF CODE. In fact, he told me it even has a comment that says > "Eat the null" !!! Oops, sorry folks, I meant to say he went to the source code for the tty000 *driver*. -- Jim Rosenberg CIS: 71515,124 decvax!idis! \ WELL: jer allegra! ---- pitt!amanue!jr BIX: jrosenberg seismo!cmcl2!cadre! /