I have gathered a bit more information. The problem I'm having always ends
up in the same place - line 403 of vfs_cache.c. No matter how I try and
test the value of ncpp before starting the inner for() (which bombs
dereferencing NULL in the init part), I end up getting traps with
ncpp being NULL, which is one of those can't-possibly-happen things.
1. I have found that putting an
if (panicstr) return ;
at the top of this routine necessary. When the trap happens, usually it ends
up causing a circular panic.
2. I went through this routine's parent (in the panic), dounmount(). One
of the things I discovered is that the clearing of the name cache (what
cache_purgevfs() does, I guess) happens very early in an unmount. This
means that I can put "unmount /usr" in a loop, and even though the unmount
will always fail, it will end up making the namei cache useless. Now,
It'd be sort of dopey to do this, I'll admit, but aparently it's the sort
of thing amd does fairly routinely (it must blindly attempt to unmount
every partition and the ones that don't go away must be in use). This
probably has an impact on the namei cache efficiency of amd mounted disks.
:-)
3. unmount /usr is sufficient to cause the panic, but not all of the time.
Something has to happen to set up a situation where the unmount attempt
will cause the trap.
4. My latest attempt has been to change ncpp from a stack variable to
a global (staticly declared in vfs_cache.c). This _appears_ to be working
longer than previous attempts, but just about every time I say that it
seems it croaks almost immediately. :-) It's a bit of a gross workaround
for an aparent register corruption (ddb shows that the instruction that
fails is a movl 0(%eax),%eamumble).
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
