[rescue] Break signals [was: Booting from LOM?]

Greg A. Woods woods at weird.com
Sun Feb 10 21:00:24 CST 2002


[ On Sunday, February 10, 2002 at 18:03:31 (-0600), Scott Newell wrote: ]
> Subject: [rescue] Break signals [was: Booting from LOM?]
>
> You know, I've read this bit about pulling the cable sending a break
> before, but always in relation to the Sun serial console.  I've _never_
> seen it in the embedded world or with PC hardware.  Is there something
> peculiar to the Sun hardware?  Did they add bias resistors to force the
> line into an unusual state on purpose?

What's peculiar about Sun hardware is also peculiar about the original
IBM PC serial ports, and many of the later clones.  I've not looked at
the exact specs of any recent ATX-like machines.

That peculiarity is that they don't exactly follow the EIA/TIA RS-232
(EIA V.24 for our European readers!  ;-) signalling specifications.
Instead of using proper full +/- 12 vdc drivers they use either 5 vdc
(and some hacked out 7 vdc) drivers.  Instead of using the then popular
MC1488 and MC1489 line driver and receiver chips they used the cheaper
75154 which normally only operates at 5vdc.  They are in effect using
the RS-423 electrical standard with RS-232 signalling!

The problem is that in RS-232 terms a signal between +3vdc and -3vdc is
said to be in an indeterminant state and normally this should indicate a
circuit failure.  However a floating line can sometimes appear to have
steady voltage just outside what a given receiver might ignore and thus
the UART will see a continuous '0' or '1' signal.  If I'm not mistaken a
many receivers designed for RS-232 are actually even sensitive to
differentials of 1 volt or less, aggrevating this problem.  More
detailed info about this near the bottom of this page under the heading
"Hardware-related failures":

	http://www.conserver.com/consoles/breaktest.html

Note that the duration of the BREAK signal should (and normally does)
change with the baud rate, since a BREAK is defined as a "space"
condition on an RS-232/V.24 line for more than the duration of an entire
character, including the start and stop bits.  The normal condition on
the line is known as "mark".

A space = logical 0 = positive voltage between +3 and +12V on RS-232/V.24
A mark = logical 1 = negative voltage between -3 and -12V on RS-232/V.24

This page also gives more detail, and it also describes a simple way to
use a pull-down resistor to normally hold the line in the 'mark'
condition even when nothing's plugged into it.

	http://www.cisco.com/warp/public/770/fn-tsbreak.html

Note though that this sentence from that Cisco page is obviously
very wrong:

	This prevents intentional halts except by removing the resistor,
	but does allow recabling.

So long as you can still send data it you can also still to send an
intentional BREAK signal as well (unless your terminal or terminal
server has such marginal drivers that it cannot fight the pull-down
resistor for an entire character duration).

Some Sun machines have partially "fixed" this problem by optionally more
closely following the RS-232 specifications, but it's still usually a
user-settable jumper -- the serial ports can be configured as either
RS-232 (+/- 12V) or RS-423 (+/- 5V).  Be sure you select RS-232!  Lots
of info about Sun serial ports, and these jumpers, is found here:

    http://www.stokely.com/unix.serial.port.resources/A-B-Ycablepinout.html

Note that some terminals and some terminal servers, and indeed some
cabling implementations, may generate spurious BREAK signals when
powered off (or even just when they're powered on again).  The following
page publishes the results of a semi-scientific survey of terminal
servers that are normally immune to this problem:

	http://www.conserver.com/consoles/breakinfo.html

Of course no choice of terminal or terminal server will avoid spurious
BREAKs caused by poor cabling and/or electrical noise!

> For what it's worth, I hot plug my serial console on IPX and SS2 machines
> all the time, and I've yet to see 'em halt.  But I'm running OpenBSD and
> NetBSD--maybe they don't listen for break signals.

You're probably just lucky....

NetBSD recently added a hack to ignore BREAK, but I'm not sure it's even
in 1.5.2.....

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods at acm.org>;  <g.a.woods at ieee.org>;  <woods at robohack.ca>
Planix, Inc. <woods at planix.com>; VE3TCP; Secrets of the Weird <woods at weird.com>



More information about the rescue mailing list