serial port nclist out of clists

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From - Fri Aug  4 13:34:32 2000
Path: news.randori.com!news-feeder2.wcg.net!WCG!cyclone-sf.pbi.net!216.65.16.3!news-out.nibble.net!news-in.nibble.net!headwall.stanford.edu!newsfeed.stanford.edu!sn-xit-01!supernews.com!sn-inject-01!corp.supernews.com!not-for-mail
From: Jeff Liebermann <jeffl@comix.santa-cruz.ca.us>
Newsgroups: comp.unix.sco.misc
Subject: Re: CONFIG: putc - out of clists
Date: Fri, 04 Aug 2000 10:10:02 -0700
Organization: Committee To Maintain an Independent Xenix
Lines: 84
Message-ID: <ldrloskjrf8c0ipjgmp23uir0eb20o3nqg@4ax.com> 
References: <8mc1cb$rnd$1@nnrp1.deja.com> <8me19o$c6d$1@nnrp1.deja.com> 
Reply-To: jeffl@comix.santa-cruz.ca.us
X-Complaints-To: newsabuse@supernews.com
X-Newsreader: Forte Agent 1.8/32.548
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Xref: news.randori.com comp.unix.sco.misc:64070
X-Mozilla-Status: 8010
X-Mozilla-Status2: 00000000

On Fri, 04 Aug 2000 09:10:17 GMT, pc_wilson@my-deja.com wrote:

>I am concerned that simply increasing the NCLIST parameter will mask
>the underlying problem, which I suspect lies with the
>cabling/connectors/ports.

Yep.

>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 screw 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.

>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.

>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.

-- 
Jeff Liebermann   jeffl@comix.santa-cruz.ca.us
150 Felker St #D  Santa Cruz CA  95060
831-421-6491 pager   831-429-1240 fax
http://www.cruzio.com/~jeffl/sco/   SCO stuff

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.