comp.unix.sco Technical FAQ (5/5)

comp.unix.sco Technical FAQ (5/5)

Post by Dale Le » Sat, 30 Oct 1999 04:00:00



Hi Matthew,

Thanks for you reply.

In the setup, COM1 is IRQ 4   mem addr 3f8
                    COM2 is IRQ3   mem addr  2f8

When booting Unixware, the com ports do not show at all.

After booting Unix, and entering DCU, the  IRQs and addresses are like
above.

One  note, if I enter cu -l term/01m to access the modem on line, I get a
initial "Connected"
response. From there I can enter no "AT" command, only  Cntl-C to exit.

I have tried o setup PPP to connect top my ISP. When I  execute cu -d erols,
erols is in system
file, I get message that chat script failed. I think it has to do with
serial ports, though.

I have a US Robotics 56K Voice internal modem.

I have set up PPP on Open Server with only a minor problems, but the
probablems I am
having with UNIXWARE are very frustrating.

-- Any suggestion would greatly appreciated,
    Dale

----- Original Message -----
From: Matthew Schalit <mscha...@earthlink-ack.net>

Newsgroups: comp.unix.unixware.misc
Sent: Sunday, October 24, 1999 1:31 AM
Subject: Re: serial ports

Recentky, dale...@erols.com said...
|Can anyone help me.  When Unixware 7.1 boots on my inel machine. The serial
|ports
|are not being recognized.
|
|Can anyone point me in a direction to debug this. I am guessing this is
part
|of reason
|whu dail up networking is not working.
|
|- Thanks,
|   Dale Lee

When you boot the machine and go into the BIOS setup, what are the
settings that the serial ports are getting (irq and port address)?

When the POST is finished, just before the splash screen, hit the
pause button to freeze the end of POST and see what IRQ and Address
the COM1 and COM2 are really getting.  What are they?

Then when the Uw7 system is up, go into the DCU and tell us what
the settings the serial ports are getting if any.

Thanks
Matthew

Dale Lee <dale...@erols.com> wrote in message
news:7uthgh$2m$1@autumn.news.rcn.net...
> Can anyone help me.  When Unixware 7.1 boots on my inel machine. The
serial
> ports
> are not being recognized.

> Can anyone point me in a direction to debug this. I am guessing this is
part
> of reason
> whu dail up networking is not working.

> - Thanks,
>    Dale Lee

Steve Dunn <ste...@united.ussinc.com> wrote in message
news:scotec5939189642@united.ussinc.com...

>   Questions and Answers about Serial Communications and UUCP
>   **********************************************************

>   My serial connections are losing characters
>   ===========================================

>   Here are three possibilities. First, check the NCLIST kernel parameter.
This
>   governs how many CLIST structures are allocated; these are used to
buffer
>   input and output. If this is too low, then at times of high serial I/O
>   demands, your system will run out of CLIST structures and start
discarding
>   characters. Note that there is a limit as to how many CLIST structures
may
>   be allocated to an individual process, regardless of how many are
available
>   systemwide. This is done to prevent one misbehaving program from
>   monopolizing all of the CLIST structures. Look for the tunable parameter
>   TTHOG (only available in newer Unix systems), which controls this limit.

>   The next possibility is that you may have an old UART (8250 or 16450).
See
>   the next answer for more info.

>   And you may also have flow control problems. The devices at either end
of a
>   serial cable must agree on what flow control is being used or else you
can
>   end up with data loss, unexplained pauses in the data stream, etc. See
the
>   man pages for stty and termio for more information on the available
>   settings.

____________________________________________________________________________

>   What do the terms UART, 8250, 16450 and 16550 mean?
>   ===================================================

>   UART means Universal Asynchronous Receiver/Transmitter. This is a chip
which
>   receives and transmits data serially; each serial port you have will use
>   one, though it is possible that several may be integrated into one chip.

>   8250, 16450 and 16550 are all common types of UARTs. The 8250 is an old
chip
>   which cannot run at high speed. The 16450 is similar to the 8250 except
>   that it supports data communications at higher speeds. Both of these
chips
>   generate an interrupt for every character that is sent or received,
which
>   basically tells the CPU either "Here is some data for you" or "Feed me!"
>   This is all very well, except that at high speed, the number of
interrupts
>   (nearly 4000 per port per second at 38 400 bps) can overwhelm a CPU,
>   bringing system performance way down. Also, if the CPU is busy servicing
>   another interrupt at the time, the serial port's interrupt may not be
>   serviced in time, which will cause a character to be lost.

>   The 16550 is pin-compatible with the 16450 and, by default, runs in
16450
>   mode. This makes it compatible with software which is not 16550-aware.
If
>   your software is 16550-aware, it can turn on a special mode in which the
>   16550 buffers all data with 16-byte internal buffers. This not only
allows
>   the CPU to deal with far more bytes at a time, increasing efficiency,
but
>   also means that if the CPU can't service the interrupt before the next
>   character comes in, there's still space in the buffer for it.

>   16550 support was introduced in Xenix 2.3.4, ODT 1.1 and Unix 3.2.2. If
you
>   have these, or later, versions, your operating system will automatically
>   detect 16550-equipped ports and will enable their buffering. A
third-party
>   serial driver called FAS includes 16550 awareness in its feature set;
you
>   may wish to investigate this as well. FAS can be found at
>   ftp://ftp.fu-berlin.de/pub/unix/driver/fas/.

>   Note that the above is not really applicable to intelligent multiport
serial
>   cards. While these cards may well use 16550s, it is the processor on the
>   serial card which is responsible for dealing with the serial ports it
>   controls, and the main CPU has nothing to do with the UARTs.

____________________________________________________________________________

>   How do I adjust my 16550's trigger level?
>   =========================================

>   The answer is different for Unix and Xenix, but much of the information
is
>   the same, so it's been grouped together here. We will deal with the
common
>   information first, and the specific details for Xenix and Unix.

>   By default, Xenix and Unix set the 16550's trigger level to 14. This
means
>   that once fourteen characters have been received, the 16550 will
generate
>   an interrupt (it will also generate an interrupt if the buffer is not
full
>   but serial data flow has stopped, so the system doesn't always have to
wait
>   until the trigger level is reached). This give the system two character
>   times in which to begin to clear the buffer; at high speed on a highly
>   loaded system, this may not be enough, and you may still lose characters
>   even though you have a 16550. On the other hand, this value should
>   generally be set as high as possible to reduce the number of interrupts
>   generated; servicing an interrupt is quite costly in terms of CPU time.

>   There is an array in the kernel called sio_fifoctl[]. It is a 16-byte
array
>   with control values for different minor numbers. To find which array
>   element will be used for a particular serial port, AND the minor number
of
>   the port with 0x0F (for example, /dev/tty2A has a minor number of 136
and
>   /dev/tty2a of 8; either one ANDed with 0x0F yields 8, so sio_fifoctl[8]
>   controls this port).

>   There are four different values you may wish to use for the entries in
>   sio_fifoctl[]. A value of 0x0F sets the trigger value to 1; 0x4F sets it
to
>   4; 0x8F sets it to 8; 0xCF sets it to 14 (these values are determined by
>   the 16550 itself, not by SCO, and other values will not set the trigger
>   level to intermediate values).

>   In Xenix, this parameter is set by patching the disk image of the kernel
>   (/xenix) using adb (the info on how to find adb is elsewhere in this
FAQ).
>   The following is a sample adb session to change the trigger level of
>   /dev/tty2A to 8 from 14 (the line numbers in parentheses are for the
>   explanation below); the asterisks are adb's prompt and should not be
typed
>   in:

>   1. cp /xenix /xenix.save
>   2. adb -w /xenix -
>   3. * sio_fifoctl+8/x
>   4. sio_fifoctl+0x8: 0xcfcf
>   5. * sio_fifoctl+0x8/w 0xcf8f
>   6. sio_fifoctl+0x8: 0xcfcf= 0xcf8f
>   7. * $q

>   Line 1 makes a backup, and line 2 runs adb in write mode. Line 3 tells
adb
>   to print the current value of sio_fifoctl[8]. Line 4 is adb's reply,
which
>   includes two bytes from this array (the rightmost one is the value for
>   sio_fifoctl[8], and the leftmost is for sio_fifoctl[9]). You must look
at
>   these carefully, as one half will have to be changed while the other
will
>   have to be left alone. In line 5, we write 0xCF8F into this location;
note
>   that the value for sio_fifoctl[9] is left unchanged at 0xCF. Line 6 is
>   adb's reply giving the old and new values. Line 7 quits adb.

>   For Unix, there is a table at the end of the text file
>   /etc/conf/pack.d/sio/space.c which gives the same array. It is formatted
in
>   the same manner (to find the appropriate value, AND the minor device
number
>   with 0x0F).

>   If you run Unix, check the man page for the sar command to see if you
have
>   the -g option to check for serial I/O overruns. If so, try running it.
If
>   you see overruns, this indicates that your trigger level is set too high
>   and the system doesn't have adequate time to service the 16550. The cure
is
>   to turn the trigger level down one notch and try again.

>   The information for Xenix in this answer is taken from the
>   comp.unix.xenix.sco FAQ, maintained by Chip Rosenthal. The copyright for
>   that document reads:

...

read more »

 
 
 

comp.unix.sco Technical FAQ (5/5)

Post by Matthew Schal » Sun, 05 Dec 1999 04:00:00



Dale, what happened to this post?  It's all long and
posted to a different ng?  I just snipped it anyway...

|Hi Matthew,
|
|Thanks for you reply.
|
|In the setup, COM1 is IRQ 4   mem addr 3f8
|                    COM2 is IRQ3   mem addr  2f8
|
|When booting Unixware, the com ports do not show at all.

Uw7 does not have a hwconfig -h sort of output at boot time.
Don't expect to see anything except some S##script output.

|After booting Unix, and entering DCU, the  IRQs and addresses are like
|above.

Good, they are there and ok.

|One  note, if I enter cu -l term/01m to access the modem on line, I get a
|initial "Connected"
|response. From there I can enter no "AT" command, only  Cntl-C to exit.

That means that it works.
Try an ATZ and enter then AT and enter.  Anything?
How about an ATE1V1 then enter then AT then enter...  Anything??

Regards
Matthew

|I have tried o setup PPP to connect top my ISP. When I  execute cu -d erols,
|erols is in system
|file, I get message that chat script failed. I think it has to do with
|serial ports, though.
|
|I have a US Robotics 56K Voice internal modem.
|
|I have set up PPP on Open Server with only a minor problems, but the
|probablems I am
|having with UNIXWARE are very frustrating.
|
|-- Any suggestion would greatly appreciated,
|    Dale
|
|