Outstanding response, once again! Even over a holiday weekend.
Many thanks for the help!
Original question:
While doing a cat < /dev/ttya in order to read a file in over the
serial port, I get a system panic and crash. The following message is
in the log file:
newmsg out of blocks output echo char out of blocks
ldmsg rsrv out of blocks
Any help and what this means and what can be done to fix it
would be greatly appreciated. This occurs on a Sparc 2 with
64 Meg of RAM, about 120 Meg of swap space running SunOS 4.1.2.
We have the kernel configured for 64 MAXUSERS, otherwise using
the generc kernel. The serial line is directly connected to
another similar SS2 and we are ruuning at 9600 baud. The exact
command looks like "cat < /dev/ttya | filterall "
filterall is a C program which reads stdin, filters certain lines
out of the input file and writes an output file.
Correct responses:
1) Make sure getty is turned off.
2) Turn off echo on /dev/ttya. Trick -- must hold /dev/ttya with
a "phantom" process, do it doesn't get reset when process
exits. Here's how: (stty -echo ; sleep 1000000) > /dev/ttya &
3) Why were we doing a cat < /dev/ttya | filterall instead of
filterall < /dev/ttya ? Mostly historical reasons. We used
to "tee" the input from /dev/ttya to another files.
We eliminated that this time.
4) A fancier fix would be to use ioctl to directly read /dev/ttya
and avoid any echoing that way. I'm a little too lazy to
try this right now.
5) Finally, here's an in-depth explanation of the error message
from kalli!kevin@fourx.Aus.Sun.COM (Kevin Sheehan {Consulting Poster Child})
ldmsg is the Line Discipline module that is pushed into the stream
for normal serial work - it simulates the 4.N BSD line discipline
interface. If you can make you application lose this interface and
use termios instead, you can pop it off the streams stack.
The basic problem is that you are running out of dblks, which are
the resource all streams driver use. You can up these in param,
but I would recommend using pstat -S (and other friends in the
*stat* family that deal with stream) to find out where the problem
is.
If you can get away with using termios, or setting mode and doing
an I_POP to get one less module in the path, then I'd go with that.
If not, then finding the clog (which tells you what size dblk you
are running out of) and upping that should be the answer.
6) Also, a reminder to check the serial cable itself from
trdlnk!mike@uunet.UU.NET (Michael Sullivan)
Check that the modem control input signals (CTS, DSR, and CD) are properly
connected to a valid signal. If you happen to wire the serial port in such a
way that these inputs are connected at the Sun end, but open at the remote end
of the cable, those conductors in the cable will inductively pick up noise
(probably from the neighboring data conductors). Each transition on one of
these signals causes an interrupt and the resulting extremely high level of
interrupts can panic the Sun (which is arguably a device driver bug).
If you don't have a meaningful source of CTS, DSR and CD signals, just tie
them to the Sun's own local DTR signal; this will keep them active whenever
the port is open.
Honor roll:
trdlnk!mike@uunet.UU.NET (Michael Sullivan)
kalli!kevin@fourx.Aus.Sun.COM (Kevin Sheehan {Consulting Poster Child})
Colin Macleod <cmacleod@mcs.dundee.ac.uk>
wallen@cogsci.UCSD.EDU (Mark R. Wallen)
mdl@cypress.com (J. Matt Landrum)
Perry_Hutchison.Portland@xerox.com
Dieter Muller <dworkin@shiara.rootgroup.com>
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:50 CDT