Phil Budne <phil@ultimate.com> writes:

  > I used mine regularly before the vnode panic problem became such a
  > pain.  Can anyone suggest any way to try and find the problem?

Well, it seems a lot less frequent now. There has been quite a lot of
work on vnode locking in MI parts of the kernel so I'd try a new
kernel.

I do still get occasional vnode panics. (Maybe once a month or
less). I don't really know how to go about tracking this down further
given it is hard to reproduce reliably. It does seem to be alleviated
by lots of memory. I think you only had 8MB is that right?

I'd work on the assumption that it is a problem in machine dependent
code since no one else has reported it. Vnodes are used by mmap code
which interacts with pmap, so maybe something in there? Maybe a grep
for "vnode" in the pc532 part of the tree would be a start (I'm sure I
did this but don't remember what I found).

Racking over core dumps doesn't seem very enlightening. Maybe I just
don't know where to look but I suspect that the panic is happening
long after the real damage has been done. Some code which does the check
earlier would be a help.

A big help would be a "killer" app which reliably casues the panic.

Another annoyance is gcc has stopped working (that is 2.95.1 and
2.95.2 from FSF not the gcc in the tree which may still be an older
version, I haven't checked).

Basically they made some big "improvements" to the register allocator
which does indeed cause better code to be generated, but also results
in being unable to compile a lot of code due to insufficient spill
registers. I'm working on it, but with strictly limited time since
my family has recently grown by one more!

Ian