Subject: vrele: bad ref count: panic running OSF1 executables
To: None <port-alpha@netbsd.org>
From: Michael L. Hitch <mhitch@lightning.msu.montana.edu>
List: port-alpha
Date: 05/21/2004 21:38:11
vrele: bad ref count: tag 1 type VREG, usecount -1, writecount 0, refcount 1,
        tag VT_UFS, ino 3096329, on dev 8, 3 flags 0x10, effnlink 1, nlink 1
        mode 0100555, owner 271, group 0, size 204800 not locked
panic: vrele: ref cnt vp 0xfffffc00025073a8
Stopped in pid 11.1 (sh) at     netbsd:cpu_Debugger+0x4:        ret    zero,(ra)

This panic has been reported a couple of times on port-alpha, and I had
run into it several months ago.  A cursory look at the code at the time
resulted in little clue to the problem, so I just never updated past that
point.

I recently needed to run a -current kernel in order to troubleshoot a
pthreads problem, and decided to make another attempt at this panic.
As a result, I determined that this was actually two different bugs.
The panic was one bug triggered by a failure in starting the OSF1
executable.  The failure to start the OSF1 executable was another bug
that was caused by a couple of previous changes.  One change was done
as part of the non-executable stack work done earlier, and the second
was a change in uvm_map_findspace() which resulted in fixing a bug which
allowd OSF1 executables to run after the non-executable stack changes.

The panic problem is now documented in PR kern/25663, and the failure
in starting OSF1 executables is documented in PR kern/25664.  Both
PRs include a workaround fix which I used to get OSF1 executables
to run again.

--
Michael L. Hitch			mhitch@montana.edu
Computer Consultant
Information Technology Center
Montana State University	Bozeman, MT	USA