From owner-freebsd-current Tue Feb 22 13:38:57 2000 Delivered-To: freebsd-current@freebsd.org Received: from guardian.sftw.com (guardian.sftw.com [209.157.37.25]) by hub.freebsd.org (Postfix) with ESMTP id 2F4E937B705; Tue, 22 Feb 2000 13:38:51 -0800 (PST) (envelope-from nsayer@sftw.com) Received: from yoda.sftw.com (a-211.sftw.com [209.157.37.211]) by guardian.sftw.com (8.9.3/8.9.3) with ESMTP id NAA39735; Tue, 22 Feb 2000 13:38:47 -0800 (PST) (envelope-from nsayer@sftw.com) Received: from sftw.com (localhost [127.0.0.1]) by yoda.sftw.com (8.9.3/8.9.3) with ESMTP id NAA00790; Tue, 22 Feb 2000 13:38:47 -0800 (PST) (envelope-from nsayer@sftw.com) Message-ID: <38B301E6.23151221@sftw.com> Date: Tue, 22 Feb 2000 21:38:46 +0000 From: Nick Sayer Reply-To: nsayer@FreeBSD.ORG X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 Cc: freebsd-current@FreeBSD.ORG, freebsd-emulation@FreeBSD.ORG Subject: Re: Weird AMD panics caused by VMware?! References: <20000217221219.A448@jupiter.delta.ny.us> <38B2F3E8.C8FF1F21@sftw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG To followup to myself, I think I have this pinned down... In line 403 of /sys/kern/vfs_cache.c, ncpp is somehow becoming 0. I believe that the trap is in ncp = LIST_FIRST(ncpp); -- LIST_FIRST(x) expands to ((x)->lh_first). That ends up being a dereference of NULL, which causes the trap and panic. As to how ncpp ends up being null, that's a good question, given it's the variable in the for loop at line 402. cache_zap() can't really have a side effect, since ncpp is a stack variable. I am going to try rewriting the outer for() loop as for(i=nchash ; i>=0 ; i--) and the initialization of the inner loop as ncp = LIST_FIRST(&(nchashtbl[i])) just in case cache_zap() causes the value of nchashtbl to change (just how the hell THAT would happen is way beyond me). Nick Sayer wrote: > (crossposting to -current in case it's not VMware related) > > I have a serial console running on the machine, so now I can tell the > difference between > a panic and a hang. :-) > > With that said, I now have a complete dump from one of these trap panics. > Here is a > stack trace: > > #0 0xc0152d28 in boot () > #1 0xc01530ac in poweroff_wait () > #2 0xc02571f9 in trap_fatal () > #3 0xc0256ed7 in trap_pfault () > #4 0xc0256a9a in trap () > #5 0xc0177da0 in cache_purgevfs () > #6 0xc017e6f1 in dounmount () > #7 0xc017e681 in unmount () > #8 0xc0257437 in syscall () > #9 0xc024b946 in Xint0x80_syscall () > #10 0x8057585 in ?? () > [etc] > > The machine is running amd, and my home directory is amd mounted. That is > the only > conceivable reason I can think why an 'unmount' would be in progress. > > Sure enough, ps aux on the core shows: > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > root 841 97.7 0.0 1100 0 ?? R 31Dec69 0:00.00 (amd) > nsayer 699 8.5 0.0 59480 0 #C1 R 31Dec69 4:46.96 (vmware) > root 2 0.0 0.0 0 0 ?? RL 31Dec69 0:03.56 > (pagedaemon) > root 3 0.0 0.0 0 0 ?? DL 31Dec69 0:00.42 (vmdaemon) > root 4 0.0 0.0 0 0 ?? RL 31Dec69 0:00.00 (bufdaemon) > > root 5 0.0 0.0 0 0 ?? RL 31Dec69 0:02.17 (syncer) > [...] > > Does anyone recognize this? What other information can I get that would be > of use? > > "Vladimir N. Silyaev" wrote: > > > > My machine here at the office gets these a _lot_ whenever I'm running > > > vmware: > > [skipped] > > > > >This machine also seems to hang a lot, but it could be that the hangs > > >are just these happening behind X so I can't see them. > > As you wrote below, you are have another box. So just try to use > > serial console (that will be provide a possibility to always > > see a panic message), also will be a right thing to compile kernel > > with DDB, that will provide some more information. > > > > > They always happen with amd as the current process. They frequently > > > happen when > > >vmware is running. They never happen at other times. > > The FreeBSD vmmon has a 'historical' bug - it's clear 'GS' register. > > But I was never encounter problem with them. And more I was > > so impressed by the fact that I was never encountered any vmware(vmmon) > > related problem. > > > > -- > > Vladimir Silyaev > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-emulation" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-emulation" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message