> "Greg A. Woods" <woods@weird.com> wrote:
> [ On Friday, May 3, 2002 at 05:24:18 (-0700), Don Yuniskis wrote: ]
> > Subject: Re: SparcStation ipx versus Sparc Classic
> >
> > But, what it "protects" against shouldn't be a problem.  EIA232
receivers are
> > designed to "see" a floating input safely
>
> Well, are you not the one complaining about the problem?  Why don't you
> try the fix -- maybe your receivers are not designed correctly....

Um, already *tried* the "fix".  Hence my previous comments that it
"doesn't work"

As far as the "receivers"... they aren't *my* receivers, they are *Sun's*
receivers!  The box that I have sitting in series with the *one* Classic
that "solves" this problem has no problems with any of the "problem"
devices being plugged/unplugged...

That, to me, lends a good deal of suspicion on where the
"problem" lies.  :>

> >   -- note that with nothing plugged
> > into the connector, you don't see an endless or intermittent stream of
> > "false BREAKS".
>
> It's usually the making of the connection that causes the problem (and
> sometimes the disconnect if you pull the plug on the terminal end, not
> the host end).
>
> That's just the nature of transmission lines, especially in an
> electrically noisy environment....  Use of better cables, with proper
> grounding helps.

4 foot shielded cable.  Residential environment.  Besides the SPARC,
typically only another SPARC and the NCD/laptop/portable/etc. that
is trying to be the serial terminal.

House is wired with 12/3 and "earth" is less than 30 electrical feet away.

I imagine most offices/busineeses are an order of magnitude (or more)
"noisier" -- both conducted and radiated.

> > 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.
>
> Well, yeah, DUH!  :-) -- so don't run your consoles over 19.2kbps, or
> even 9600bps!  (you should probably leave themn all at 9600 anyway since

You'll note that (older) SPARCs can't *do* much over that realistically.
Aside from modems, all of the serial ports here are set at 9600bps --
I don't want to have to wonder if the line characteristics are set properly
when two particular devices refuse to communicate.

At 9600bps, it's a millisecond to exceed the word width.  So, close
to 2.5ms to have a "real" BREAK -- and that assumes the line
doesn't "ring" (but stays SPACE-ing for the full 2.5ms)  That's a fair
amount of time -- hard to imagine the stored energy in a 4 foot cable
being enough to drive that line more than 3V above ground for that
amount of time when the (active) device being attached is driving it
to something below -3V (i.e. the case of the "plugging in cable").

Arguable how much energy there is in the same cable when
it is being *un*plugged (thereby lacking the "assistance" of the
driving source).

Even the "powered up while connected" scenario makes little
sense (except possibly for devices using charge-pump drivers)
since the transmitter inverts and it would be more UNlikely
for it to "see" a "1" at it's input than a "0" if the driving
logic was still powering up (an exception here might be
"PC's" using Combo's for their serial ports.. these being
of indeterminate state until the BIOS gets around to configuring
those pins as outputs... I suspect few designs include the required
pullDOWNs on those inputs to the transmitters)

> that's likely the default and there are many many advantages to keeping
> all like devices at the same speed and at their factory default speed --
> just make sure you re-tune their console logging so that it's very
> infrequent or even completely off)

> > > (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.
>
> The offending terminal device is poorly designed.  Get rid of it or fix
> it.  :-)

From comments here and in references on the WWW, it appears that
much of the "world" is "poorly designed", by this criteria.  Methinks
the problem might be more *Sun's* than "the rest of the world
(especially noting how the SS5 "appears" to have been "fixed"?)
If I have a spare moment tonight, perhaps I'll tether another
SPARC to the serial console (via null modem) and see if *it*
BREAKs the line when *it* powers up!  :>

> >  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).
>
> You're not taking into account the effects of the transmission lines.
>
> > I would much prefer if the "feature" was implemented in a more robust
> > manner.
>
> :-)
>
> Well, you could always buy a bunch of converters that convert your
> host's console ports to some more reliable physical interface and use
> that instead!  :-)

Or, if someone would answer my previous query asking for exacly
how and where this is implemented, perhaps a *better* solution
could be derived -- one that might benefit *others* instead of JUST ME!
(gee, imagine that!  :>)

So, again, can someone explain where the break is detected?
Where it is acted upon?  I.e. is the code in the ROM monitor still
active in the NBSD kernel?  (either executing out of the ROM *or*
copied into VM someplace)  Does *it* unilaterally decide
to drop you into the ROM monitor?  If so, how does the
kernel option to invoke the (kernel?) debugger fit in?
Are there hooks in teh OpenBoot configuration that let you
disable this feature (despite NBSD's presence/absence)?

If you do disable it, what do you lose? Just the ability to
drop into the kernel (if so configured) *or* the ROM
monitor?  I suspect many folks would readily forfeit
that -- I would even suggest it should be the default state
for the kernel  (If you're savvy enough to want to kernel
debug, chances are you can build your own kernel!)

Perhaps my early experiences in this industry have me biased...
software solutions being preferable to hardware ones (since,
as a manufacturer, you can implement software fixes far more
cheaply than hardware ones -- if you have an existing product
base in the field)

> Or you could run permanent console connections to a reliable and well
> designed terminal server....  (which is what I do)

Not an option, here.  It would mean running (long) serial cables all
over the house to tie all those machines together.  And, given that
I rarely *need* the "console" (since I don't turn off the oscillator
when taking a machine out of service -- the subject that started
this thread  :> -- and usually don't have "unexplained" crashes
where I need to talk to a box single user,e tc.) it would be a colossal
waste of effort.  (Most of the older SPARCs will be retired soon
as I bring more designs online)

> >  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.
>
> Yeah, well if people always used things in the manner they were intended
> by the original designer then there'd be a lot less problems overall...
:-)

From my experience, it usually is an indication that the original designer
didn't have enough foresight to envision how things *would* be used!
Kinda hard to say "I did it right" when all these devices are having
problems with your implementation choices.

Sort of like buffer overruns in software ("Gee, I didn't *expect*
someone to type in more than 8 characters....")  :>

Does Sun's (original!) documentation say "whatever you plug in the console
port must remain powered up at all times"?  Or, more likely, have they only
acknowledged the problem after the fact -- "Ooops!  To work around this
problem, do the following..."?

> If you put your machines all in the environment they were designed for,

And, what environment, exactly, is that?  Where have you seen this defined?
I sure would like to see where Sun has told me what *not* to do...

> and if you used your RS-232 serial console connections _only_ in the way
> the EIA specs allow for, then you won't likely have any problems.....

You will note that EIA232D makes no claims or prohibitions regarding
plugging or unplugging connections.  It makes no claims about the
"content" of the data path it implements.  Most actual implementations
bend several rules regarding electrical characteristics (of course, the
simple choice of connectors/pinouts on Classic, IPC, etc. all violate the
mechanical dictates of the "standard").  So, I don't think Sun has
any claim to the high moral ground regarding how they "intended"
this interface to be used.  :>

You will also note that the way "hardware handshaking" is implemented
on almost *all* devices is NOT in conformance with EIA232D.
Heck, most of the "circuits" are no longer even present in most 232
interfaces -- even those that use DB25's.  Nowadays, charge pump
transceivers push the margin on what is/is not acceptable interface
characteristics -- worth noting that at least one of the portables I'm
using and both of the NCD's use "genuine" receiver/transmitters.
IIRC, the NCD even goes to extra lengths to ensure the output is
properly slew rate limited *and* biases the receivers to get the correct
switching thresholds and hysteresis.

So, hard to say *they* didn't "do their best"...  I should peek inside
one of the SPARCs to see what *their* interface looks like...
(sigh... when are we going to have an Open Hardware revolution?)