>I am concerned that simply increasing the NCLIST parameter will mask
>the underlying problem, which I suspect lies with the
>cabling/connectors/ports.
Yep.
Quote:>The comms company who did the structured wiring fully tested all the
>Cat5 at the time and fixed any problems they found, although I have
>since fixed a few popped krones.
Oh-oh. I've found that cabling companies either get it perfect, or
totally*it up, with nothing in between. If you're finding wiring
or crimping errors, you'll probably find they're epidemic. You probably
can't afford a cable certifier, but you might consider buying one of the
under $100 testers that check continuity.
Quote:>I assembled the RJ to DB adapters (the
>push-pin variety - never could use a soldering iron) myself with only
>pins 2,3 and 7 wired.
Thank you for *NOT* including the "protective" ground. That probably
saved you some difficulties.
Pins 2,3 and 7 are all you need if:
1. You're not using hardware flow control.
2. You're not using the upper case modem control port names such as
/dev/tty1A. These will required doing something with Pin 8 (carrier
detect).
3. You don't have long wires going to pins 5 and 6 which can act as an
antenna and pickup crud.
4. Your unspecified smart serial port vendor isn't a really ancient
Digiboard Com8i that doesn't "float" the inputs high and require that all
inputs (pins 4,6,and 8) go somewhere. If you're not sure, try 4-5 and
6-20 on the unspecified serial port end. If you're using modem control
port names, it's 6-8-20.
Quote:>Any advice on how best to troubleshoot this one would be much
>appreciated. Are there any tools/testers available to
>detect "chatter"ing terminals?
The last time I did this was 7 years ago, so the memory is a bit foggish.
I wish I had some kind of utility that displays CLIST consumption.
u386mon does not display CLIST consumption. That leaves "crash".
The rule-o-thumb for NCLIST is 10ea per tty serial connection including
multi-sessions. So, if you're using mscreen, discreen, or Faceterm, you
need to include those sessions. Also include serial printers. The
buffers are small so a large number is no problem.
OSR5 has nifty feature that prevents miswired serial devices from
becoming a nuisance, but may hide the problem. In the boot(F) man page,
the parameters:
INHIBIT=n
If an inittab entry is respawned SPAWN_LIMIT times within
SPAWN_INTERVAL seconds, init will not try to
respawn that entry for this many seconds (unless a ``telinit q''
is done). The default value is 300 seconds (five minutes).
SPAWN_INTERVAL=n
If an inittab entry is respawned SPAWN_LIMIT times within
this amount of time (seconds), init will not try to
respawn that entry for INHIBIT seconds (unless a ``telinit q''
is done). The default value is 120 seconds.
If these were reduced to a much smaller number, your flakey serial port
might be easier to troubleshoot as the problems will appear more often.
In my limited experience, having getty running on a serial printer port
can cause CLIST overflow. I don't understand why this should be, but one
such problem was caused by this. However, garbage pickup, due to
unterminated inputs and wiring errors was far more common. The modular
plug to DB25 adapters were the major culprit with creative wiring as a
close second.
Good luck.
--
150 Felker St #D Santa Cruz CA 95060
831-421-6491 pager 831-429-1240 fax
http://www.veryComputer.com/~jeffl/sco/ SCO stuff
by