STREAMS tty driver problems..
Leonard Sitongia
sitongia at hao.ucar.edu
Fri Nov 17 06:52:52 AEST 1989
In a previous article, sdl!monet!gregt at 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 at hao.ucar.edu
More information about the Comp.sys.sun
mailing list