The break issue on sparcs has been known about
and beaten to death over and over and over.

It was my impression that there had been a sysctl
call added which can be set from the command line (or
in the system startup files) to disable the break
dropping back to the ROM monitor.  There was definately
discussion about doing this.

I have sparc classics and ss5 and plug and unplug pc
laptops into the serial ports while they are running
with never an ill effect.

It is a fact that all the laptops and pc clones
that I have seen generate a break somewhere near
the power on, so if the pc is plugged into the
sparc WHILE the pc is powered on, the sparc WILL
return to the ROM monitor.

It was my impression that the break happened quite
a while into the power up sequence on the PC.  If
this is true, then it would point to the PC bios
intentionally sending a break as part of the
initialization sequence, and not due to power supply
fluctutation [as can certainly be the case in other
hardware.]  If this is true, one could go in and alter
the PC's bios, if you REALLY had a lot of free time.

A break could be interpreted by attached hardware as
a request from the PC for a reset.  Who knows what was
in the mind of the early PC hardware designers?

The processing of the serial bits coming in on the wire
is done by the UART (a chip), which decides when a break
occurs, and not the OS.  A bit in one of the status
registers will be activated when the UART decides a break
(or overrun, or parity, etc) occurs.  It is up to
the OS to look at, or ignore, this status word and
take some action, typically while reading the character,
eg, test for a transmission error before processing the
character.

When I looked at the kernel code long ago, the action
of the NetBSD kernel was to call an entry point in the
PROM chip (the EPROM on the sparc motherboard) which
then starts up the ROM monitor.  One could simply
remove that line from the kernel code and recompile
a kernel which would ignore breaks.  I think I did that
long ago, and I think it worked.

Presumably, the sysctl function (if it were ever
implemented) controls this from the command line,
without the need to recompile a kernel.

NetBSD may behave differently on different ports since
in the past different ports have had different kernel
options enabled/disabled.  Also, the serial port drivers
might more fully implemented on some ports.  One could
have the serial port driver ignore the break bit.

It has been desirable for various OS to drop to some
ROM monitor in the past: most/all Sun hardware and
DEC hardware (VMS) does it.  In my opinion, we should
not be distributing NetBSD with this option enabled
due to the robustness issue.  See PR/11946 as you can
generate a "break" on a 19200 baud line by sending
a charater at 110 baud.  Don't even need a break key!

And given the fact that the sparc install floppy will
change the baud rate of the serial console without
warning, and the system is likely to crash at install.

I think this is confusing for new users and irritating
for everyone else who forgets to unplug their cheap PC
terminal from the sparc when resetting the PC.

Also, in my opinion, the resistor is not going to do
much to solve this issue... that was the solution to
another problem... a terminal (or cable) which did not
implement some signals (like DTR or CTS) which the OS
wanted to detect a powered up terminal, and turn on a
getty.

Those OSs were designed that way.

The "immunity" boxes probably have two UARTs back-to-
back... the 8 bits collected from the receiving end
of one are passed to the transmitting part of the
other.  Each incoming character would strobe the same
outgoing character.  The status word which would have
the break bit would proposely not be passed on to the
transmitting half, and thus the break would be blocked.

I can't imagine any analogue circuit which would
reliablly "filter" out the break and pass the "desired"
signals.

I hope that the sysctl to disable the break action has
been implemented... This will solve most of our issues.