jhc@mtune.UUCP (09/03/87)
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.