gregt@uunet.uu.net (Greg Tusar) (11/08/89)
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 :
physmem ffd
$c
_panic(0xf80cce23,0x0,0x3e8,0x1e84800,0x0,0x0) + 7c
_trap(0x9,0xffffeb64,0x0,0x80,0x1,0xc50) + 1c8
fault(0x0,0x0,0xf80e4db8,0xf8132200,0x9f,0x439) + 64
_qdetach(0xff058898,0x1,0x0,0x400ce4,0x4000e4,0x0) + 58
_strdismantle(0xf80e4db8,0x2,0x0,0x4000e5,0xff058874,0x0) + fc
_strclose(0xff13020c,0x2,0xa20,0x900,0xf80c91cc,0xf80e4db8) + 70
_spec_close(0xff130208,0xff13020c,0xff130208,0x4801,0x4801,0x4801) + 160
_vn_close(0xff13020c,0x2,0x1,0x29ab0,0xe12c,0x0) + 1c
_vno_close(0xf81244ac,0xf80d4800,0x4,0xf80e4db8,0x1,0xff13020c) + 3c
_closef(0xf81244ac,0x400fa4,0x1000,0xf8127f84,0x408001,0x13) + 84
_close(0xffffefe0,0xf80c4448,0xf80c4448,0xfffff608,0xf81244ac,0xfffff705) + 94
_syscall(0x8000000) + 2d0
0xf80cce23/s
_sizestr+0xbf: Data fault
So I guess I have some configuration problem, but I can't find it, and we
don't have a source license. My question is, does anyone know what in
particular qdetach() takes apart? Is the fault generated by qdetach trying
to call my close routine through some structure I haven't initialized
properly? Most of the stuff like qinit, module_info and streamtab
structures were lifted directly from the Sun Driver Ed. manual. Sun
hasn't been a great source of information, one of their support group told
me "We just adopted it from System V, and no one here really knows
anything about it.." The STREAMS driver section of the driver manual
itself was stolen directly from the Systen V manuals.
This is really begining to bother me. If Sun supplants the old tty notion
with STREAMS, it really shouldn't be this mysterious..
Has anyone else had any bad experiences related to this? ANY hints
or suggestions about the qdetatch routine would be GREATLY
appreciated.
My STREAMS structs look like this...
static struct module_info rminfo = { /* read side */
0, "ob", 0, INFPSZ, 150, 50
};
static struct module_info wminfo = { /* write side */
0, "ob", 0, INFPSZ, 150, 50
};
static struct qinit rinit = {
obrput, NULL, obopen, obclose, NULL, &rminfo, NULL
};
static struct qinit winit = {
obwput, NULL, NULL, NULL, NULL, &wminfo, NULL
};
struct streamtab obinfo = { &rinit, &winit, NULL, NULL, NULL };
thanks,
greg tusarsitongia@hao.ucar.edu (Leonard Sitongia) (11/17/89)
In a previous article, sdl!monet!gregt@uunet.uu.net (Greg Tusar) writes: >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 is a known SunOS 4.0.3 bug. Ask for the patch. We were having this problem also, with crashes up to 3 times a day, with the standard Sun software, apparently because we have so many (?) serial ports (3 ALM-2 boards). 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. Leonard E. Sitongia System Programmer (303) 497-1509 Internet: sitongia@hao.ucar.edu
wheelan@calvin.cs.mcgill.ca (Bill HEELAN) (11/24/89)
>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 )