Date: Wed, 23 Feb 2000 13:23:17 -0800 From: "Nick Sayer" <nsayer@quack.kfu.com> To: <freebsd-current@freebsd.org> Subject: RE: Wierd AMD panics caused by VMWare? Message-ID: <NDBBIEIMMKHCPIPDCHGFCEAECAAA.nsayer@quack.kfu.com> In-Reply-To: <200002232043.MAA31642@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?NDBBIEIMMKHCPIPDCHGFCEAECAAA.nsayer>