Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!tut.cis.ohio-state.edu!cs.utexas.edu!rice!sun-spots-request
From: wheelan@calvin.cs.mcgill.ca (Bill HEELAN)
Newsgroups: comp.sys.sun
Subject: Re: STREAMS tty driver problems..
Keywords: SunOS
Message-ID: <3315@brazos.Rice.edu>
Date: 23 Nov 89 22:25:54 GMT
Sender: root@rice.edu
Organization: Sun-Spots
Lines: 39
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v8n192, Replies: v8n200
X-Sun-Spots-Digest: Volume 8, Issue 208, message 6 of 19

>From article <2916@brazos.Rice.edu>, by sdl!monet!gregt@uunet.uu.net (Greg Tusar):
> I'm in the process of writing a STREAMS tty driver, and I'm having a
> rather tough time of it. The driver is for an Omnibyte OB68K board which
> sits in a Sun 4/260 (SunOS 4.0.3)..
> 
> The specific problem that I've run up against is that when a port is
> closed, and the stream is getting dismantled, something in qdetach()
> generates a data fault... My close routine is nowhere in the call stack
> trace. The actual call stack trace looks like this :
[ ... ]

This looks similar to a problem we were having with our Sun 4/280, also
running 4.0.3, which was causing it to crash up to twice a day.

The problem was described in a Sun bug report:

        BUGID     Synopsis

        1025622   Panic bus error in streams close code

The panic was being caused by a naive fix to #1019499, which introduced a
race condition in the streams open/close code that could cause a stream to
be torn down even though someone else was in the middle of opening it; the
resulting corruption of data would cause the system to panic at some later
time, normally after carrier was detected, getty opened the line, called
vhangup, and closed the line. Specificly, the panic would occur most often
during the "close" above, since the queue's q_qinfo pointer pointed at
something unexpected. The fix is to back out the original fix for
#1019499, and modify the streams code to properly handle the case of
background processes holding a stream open that has been hung up.

We installed the patch, which fixed the problem.

Look for the "Serial I/O" patch in the sunpatches directory on
ugw.utcs.utoronto.ca ( 128.100.102.3 ).  (Thanks to Johnny Chee-Wah at
UToronto.)

                                             - Bill Heelan
                                               ( wheelan@cs.mcgill.ca )