Subject: Re: SparcStation ipx versus Sparc Classic
To: NetBSD/sparc Discussion List <port-sparc@NetBSD.ORG>
From: Don Yuniskis <auryn@GCI-Net.com>
List: port-sparc
Date: 05/03/2002 05:24:18
> "Greg A. Woods" <woods@weird.com> wrote:

> [ On Thursday, May 2, 2002 at 16:37:41 (-0700), Don Yuniskis wrote: ]
> > Subject: Re: SparcStation ipx versus Sparc Classic
> >
> > And, if you think about it, this solution DOESN'T WORK!
>
> Well, it does exactly what it was designed to do, nothing more, and
> nothing less....

But, what it "protects" against shouldn't be a problem.  EIA232 receivers
are
designed to "see" a floating input safely -- note that with nothing plugged
into the connector, you don't see an endless or intermittent stream of
"false BREAKS".  What it is *trying* to do is "muscle" a misbehaving
input to remain in the MARKing state despite it's attempts to glitch towards
SPACE.  I.e. put a 10 ohm resistor there and it will "pull" the input even
*more*!  (as well as no longer comply with load specifications for the
interface, etc.)

> > It prevents an "open" input from glitching to SPACE and, thus, making
the BREAK.
> > However, the output impedance of (classic) EIA232 drivers is ~600 ohms.
> > So, if the external device *drives* the line to SPACE, the resistor may
as well be
> > sitting in your desk drawer... it isn't going to *do* anything!
>
> Of course!  This modification is not designed to prevent an
> _intentional_ BREAK condition from being generated, and as a result it
> cannot prevent an accidental BREAK condition that is electrically
> identical to a real BREAK condition.

Well, there's the rub.  How do you define a BREAK?  Most simplistic
algorithms just look for 10 or more consecutive SPACES (i.e. receipt of
ASCII NUL, followed by a framing error and possibly accompanied by a
parity error -- depending on the parity setting).  As opposed to something
more definitive (like a "LONG BREAK").

At higher bit rates, the "10 SPACEs" gets easier and easier to occur
unintentionally.

> (the document I quote does claim it will prevent accidental BREAK
> conditions when a poorly designed terminal device is powered off or on,
> and obviously it can only do that in some cases, though from what I've
> seen of such problems these happen to be quite common cases....)

I have gear that causes the problem if plugged in and powered up...
or down.  I have other devices that cause the problem when powered
*up* and plugged or unplugged (which baffles me since this *should*
be safe -- unless it's a problem of variations in contact mating sequence).

> > So, you have to unplug the cable before applying power to the external
device
> > as well as before removing power from said device -- since in either
case it
> > can "decide" to drive the line to SPACE while it is in transition.
>
> And you have a problem with that?  You stated your problem was

"Problem"?  Depends how you define a "problem".  I kept a spare
battery in the trunk of my car one winter years ago until I could figure
out where the problem in the electrical system was.  If the car wouldn't
start on a given morning, I would drag the battery out and use it to jump
start the car.  Did I have a "Problem" with that?  Well, I didn't *like*
it since that's not how the car *should* have behaved.  But, I did
it for a few months until I could catch the intermittent problem
and fix it.

I run most of my SPARCs headless *because* they are in inaccessible
spaces.  Plug it in and tuck it away somewhere so that it doesn't get
in the way.  Plugging/unplugging devices often means getting on hands
and knees and crawling into some cubbyhole and groping for the
back of the machine to fiddle with connectors.  Sure, I could leave
a 25 pin M-F cable plugged into the srial port 24/7 -- but then I have
yet another cable to hide.  And I have to commit 8 such cables to
"just in case" duty (8 SPARCs in service at the moment).

I would much prefer if the "feature" was implemented in a more robust
manner.  This, of course, is a subjective assessment on my part.  Though
when you see products *advertised* as being "Sun-safe", it pretty
much seems to acknowledge that this is a problem for a LOT of people...
suggesting that a better implementation would probably have been wiser.

> accidentally halting your systems when you unplugged the console cable.

I was alluding to the *set* of BREAK-related problems associated
with the SPARCs.  I assumed this reference would be sufficient to
address that whole issue.

> I.e. that you want to prevent an "open" input from generating an
> accidental BREAK condition.  As you admit this fix will prevent that
> problem and that's exactly what it was designed to do.
>
> If on the other hand you have a terminal device that drives a
> real-looking BREAK condition when its power source is transitioned, then
> just don't turn off your terminal device when it's plugged in!
>
> (Personally I think I've only ever encountered problems when
> re-connecting a powered up terminal to the console port, and that's a
> lot less troublesome since it's easy enough to immediately start the
> system running again.)

Except that you have to *notice* that the system has halted
and, while halted, it's not doing what it was intended to do.
In my case, some act as routers, font servers, etc.  So, that
"service" is unceremoniously unavailable for the duration...
just because you plugged/unplugged/powered/unpowered
an external device.  Annoying if streaming audio was flowing
through that router at the time you decided to connect/unconnect
your "console".

> If your terminal device forces a BREAK condition even despite this
> counter-measure when you transition its power source then _you_ can
> learn not to do that.  Meanwhile this "fix" will allow you to safely
> disconnect your terminal device and move it to another system without
> risking halting the system you've just been working on, and yet still
> allow you to generate an intentional BREAK condition to manually halt a
> system on demand.

No, it makes no guarantees about what it *will* do.  It may work with
one peripheral and not with another.  The conditions that cause the
BREAK in one case can be different than in another (e.g. BREAK
when power aplied while connected implies "power up before
connecting" -- yet other devices cause a BREAK when connected
WHILE POWERED UP).  It's a non-fix.

I have a box I designed for a different purpose that "solves" this
problem for one of my machines (I only have one of these boxes  :<).
But, using it defeats the purpose of having a *small* box like
a Classic tucked away in a corner -- if I could afford the extra space
for this box, then I could likewise afford to put some *other*
box to take the place of the SPARC (e.g., a Quadra) that *doesn't*
have this "problem" (feature??).  It just doesn't seem worthwhile to
layout a smaller board "just" to make this fix more palatable (space-wise)
to the SPARC situation.

How much of this behaviour is built into the ROMs and how much
is layered on top of it (NBSD)?  E.g., NBSD allows you to let this
drop you into the (kernel?) debugger.  But, if you "disable" that
feature, won't the SPARC's boot ROMs enforce *their* behavior
(i.e. drop you to the "ok" prompt?)