serial port nclist out of clists
From: Jeff Liebermann <firstname.lastname@example.org> Newsgroups: comp.unix.sco.misc Subject: Re: CONFIG: putc - out of clists Date: Fri, 04 Aug 2000 10:10:02 -0700 Message-ID: <email@example.com> On Fri, 04 Aug 2000 09:10:17 GMT, firstname.lastname@example.org 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 email@example.com 150 Felker St #D Santa Cruz CA 95060 831-421-6491 pager 831-429-1240 fax http://www.cruzio.com/~jeffl/sco/ SCO stuff
Got something to add? Send me email.
(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Printer Friendly Version
Increase ad revenue 50-250% with Ezoic