I got a total of four responses. One person suggested using the
loadable device driver and reloading the drive to eliminate the hung
processes. One person correctly pointed out that the code that set
the flags was wrong (used flags &= !BIT instead of flags &= ~BIT), but
that was not the immediate problem. It just meant carriage return
delay was turned off, not a big problem here :-). The potentially
most useful response was from Jose Beltrami from Sun Software Support
in Uruguay. He suggested going to SunOS 4.1.2 and getting an upgrade
from Artecon. We called Artecon, but have had problems getting a
response. We do not have a service contract and I guess you get what
you pay for (not a slam, just a fact).
Thanks to those that responded:
sunuru!beltrami@Sun.COM (Jose L. Beltrami)
tfpoage@ucdavis.edu (Tom Poage)
miker@sbcoc.com (Mike Raffety)
birger@vest.sdata.no (Birger A. Wathne)
======================================================================
Original question:
We have a SS2 running SunOS 4.1.1 with an ArtePort SB-1600 16
line SBus serial port card installed with version 1.2 of their
ArtePort device driver. The device drive is built-in (versus the
loadable driver option).
In short we are having problems with the various serial ports
locking up in a state where only a reboot will allow the continued use
of the port. If anyone has such a device and can offer any help or
incite, more details follow.
On three of the ports (A0, A1, A2) instead of the standard getty,
we run a program that accepts print jobs from a PC serial port and
spools them. One PC is attached to each port. The same program runs
on all three ports. The ports are marked to use "software carrier".
ttyA0 "/usr/local/etc/pclprd PARSONS quill" unknown on local
ttyA1 "/usr/local/etc/pclprd FERGUSON quill" unknown on local
ttyA2 "/usr/local/etc/pclprd BO_PUBLIC quill" unknown on local
Under normal circumstances, the programs will open the device,
set a few parameters, issue a read, and let the read block until data
is available. If the ttytab entries are turned off at boot time, then
turned on manually afterwards this works great. It worked for over a
month with no problems -- assuming the system does not reboot.
However, if the entries are turned on at boot time, the lines
typically get locked up in a state that does not allow anything to
open them. Even after the ttytab entries are turned off, a trace of
ttysoftcar /dev/ttyA0 always shows ttysoftcar hanging on the open.
data.root 5: trace ttysoftcar /dev/ttyA0
open ("/usr/lib/ld.so", 0, 040430) = 3
read (3, "".., 32) = 32
mmap (0, 40960, 0x5, 0x80000002, 3, 0) = 0xf77e0000
mmap (0xf77e8000, 8192, 0x7, 0x80000012, 3, 32768) = 0xf77e8000
open ("/dev/zero", 0, 07) = 4
getrlimit (3, 0xf7fff990) = 0
mmap (0xf7800000, 8192, 0x3, 0x80000012, 4, 0) = 0xf7800000
close (3) = 0
getuid () = 0
getgid () = 1
open ("/etc/ld.so.cache", 0, 05000100021) = 3
fstat (3, 0xf7fff830) = 0
mmap (0, 4096, 0x1, 0x80000001, 3, 0) = 0xf77c0000
close (3) = 0
open ("/usr/lib/libc.so.1.7", 0, 036737405634) = 3
read (3, "".., 32) = 32
mmap (0, 475824, 0x5, 0x80000002, 3, 0) = 0xf7730000
mmap (0xf77a0000, 16384, 0x7, 0x80000012, 3, 458752) = 0xf77a0000
mmap (0xf77a4000, 688, 0x7, 0x80000012, 4, 0) = 0xf77a4000
close (3) = 0
close (4) = 0
open ("/dev/ttyA0", 04, 036777775154) =
The odd thing is that not all three lines will behave the same.
This particular time A0 and A2 hang, but A1 works just fine. The
particulars are not always the same.
If I put a break-out box on to the serial line and attach a
device that asserts DTR and DCD, the open still hangs. The pstat -S
output shows the following.
LOC WRQ VNODE DEVICE PGRP SIGIO FLAGS
ff0140e4 ff014dec ff089dbc 106, 2 0 0 H
Write side:
NAME COUNT FLG MINPS MAXPS HIWAT LOWAT
strwhead 0 0 0 0 0
ArtePort 0 R 0 INF 512 128
Read side:
ArtePort 0 R 0 INF 512 128
strrhead 0 R 0 INF 300 200
LOC WRQ VNODE DEVICE PGRP SIGIO FLAGS
ff01403c ff014bac ff0860e4 106, 0 0 0 H
Write side:
NAME COUNT FLG MINPS MAXPS HIWAT LOWAT
strwhead 0 0 0 0 0
ArtePort 0 R 0 INF 512 128
Read side:
ArtePort 0 R 0 INF 512 128
strrhead 26 R 0 INF 300 200
There are only entries for ttyA0 (106,0) and ttyA2 (106,2) which
is consistent with A1 working, A0 and A2 not (A1 is currently turned
off).
If I run pclprd on /dev/ttyA1, I see
LOC WRQ VNODE DEVICE PGRP SIGIO FLAGS
ff0e9384 ff11273c ff0fdffc 106, 1 0 0 R N o
Write side:
NAME COUNT FLG MINPS MAXPS HIWAT LOWAT
strwhead 0 0 0 0 0
ttcompat 0 R 0 INF 300 200
ldterm 0 R 0 INF 1 0
ArtePort 0 R 0 INF 512 128
Read side:
ArtePort 0 R 0 INF 512 128
ldterm 0 R 0 128 500 200
ttcompat 0 R 0 INF 2048 128
strrhead 0 R 0 INF 300 200
data.root 28: trace /usr/local/etc/pclprd FERGUSON quill ttyA1
open ("/usr/lib/ld.so", 0, 040630) = 3
read (3, "".., 32) = 32
mmap (0, 40960, 0x5, 0x80000002, 3, 0) = 0xf77e0000
mmap (0xf77e8000, 8192, 0x7, 0x80000012, 3, 32768) = 0xf77e8000
open ("/dev/zero", 0, 07) = 4
getrlimit (3, 0xf7fff978) = 0
mmap (0xf7800000, 8192, 0x3, 0x80000012, 4, 0) = 0xf7800000
close (3) = 0
getuid () = 0
getgid () = 1
open ("/etc/ld.so.cache", 0, 05000100021) = 3
fstat (3, 0xf7fff818) = 0
mmap (0, 4096, 0x1, 0x80000001, 3, 0) = 0xf77c0000
close (3) = 0
open ("/usr/lib/libc.so.1.7", 0, 033350) = 3
read (3, "".., 32) = 32
mmap (0, 475824, 0x5, 0x80000002, 3, 0) = 0xf7730000
mmap (0xf77a0000, 16384, 0x7, 0x80000012, 3, 458752) = 0xf77a0000
mmap (0xf77a4000, 688, 0x7, 0x80000012, 4, 0) = 0xf77a4000
close (3) = 0
close (4) = 0
getpagesize () = 4096
brk (0x67b0) = 0
brk (0x77b0) = 0
open ("/dev/ttyA1", 0, 0) = 3
ioctl (3, 0x40067408, 0xf7fffab0) = 0
ioctl (3, 0x80067409, 0xf7fffab0) = 0
read (3,
The ioctl's get and set the terminal characteristics.
if( ioctl(fd, TIOCGETP, &arg) < 0 ) /* Get current tty settings */
syslog(LOG_WARNING, "prep_tty: ioctl(TIOCGETP): %m");
arg.sg_ispeed = B9600; /* Set input speed to 9600 baud */
arg.sg_flags &= !ECHO; /* Turn off input echoing */
arg.sg_flags &= !CRMOD; /* Don't map CR to LF */
arg.sg_flags &= !RAW; /* Use cooked mode */
arg.sg_flags &= !CBREAK;
if( ioctl(fd, TIOCSETP, &arg) < 0 ) /* Set tty to new settings*/
syslog(LOG_WARNING, "prep_tty: ioctl(TIOCSETP): %m");
I did not write the actual code for pclprd, but it can be
changed. Does anyone familiar with the ArtePort device have any idea
what we are doing wrong? Any advice?
My current idea for a "solution" is to turn off the ttytab
entries. After boot, turn them on (edit ttytab), HUP init, then edit
ttytab to leave them "off". Clearly, this is a gross hack.
By the way, the lock-ups have also occured on ports that have
nothing to do with pclprd, but are just used for standard serial
printer ports. We do not run gettys on any of the ports.
Daniel Trinkle trinkle@cs.purdue.edu
Dept. of Computer Sciences {backbone}!purdue!trinkle
Purdue University 317-494-7844
West Lafayette, IN 47907
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:46 CDT