panic: vn_rele
Leonard Sitongia
sitongia at hao.ucar.edu
Thu Mar 8 03:41:05 AEST 1990
In article <5545 at brazos.Rice.edu>, haberman at s1.msi.umn.edu (Joe
Habermann) writes:
> We have a 3/260 and 3/60 that "panic: vn_rele" an a pretty regular basis.
> Both machines are diskful servers running SunOS 4.0.1 and 4.0.3,
> respectively. The 3/260 runs quotas and the 3/60 does not. It seems as
> though the panics occur during periods of high disk activity like while a
> dump is running. There are no other system errors associated with the
> panics. The panics occur on our 3/60 about twice a week or so.
I believe that this has been fixed for some time now:
@(#)README 1.1 [limes] 89/09/08 SMI
This archive contains all the changes to the serial drivers and streams
code since SunOS 4.0.3 FCS 2, and a quickie install script as an example
of how to rebuild a kernel with the new drivers.
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 Manager (303) 497-1509
USPS Mail: High Altitude Observatory P.O. Box 3000 Boulder CO 80307
Internet: sitongia at hao.ucar.edu
SPAN: NSFGW::"hao.ucar.edu!sitongia" [NSFGW=9580]
More information about the Comp.sys.sun
mailing list