From owner-freebsd-emulation Fri Mar 31 9:28:40 2000 Delivered-To: freebsd-emulation@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id D6AC137BCFC for ; Fri, 31 Mar 2000 09:28:37 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA29464; Fri, 31 Mar 2000 09:28:35 -0800 (PST) (envelope-from dillon) Date: Fri, 31 Mar 2000 09:28:35 -0800 (PST) From: Matthew Dillon Message-Id: <200003311728.JAA29464@apollo.backplane.com> To: Andrew Gallatin Cc: nsayer@kfu.com, freebsd-emulation@FreeBSD.ORG Subject: Re: VMware locks FreeBSD 4.0 solid References: <38E3FB31.3DD4D170@sftw.com> <14564.53252.962047.551231@grasshopper.cs.duke.edu> Sender: owner-freebsd-emulation@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :I'm running VMware 2.0 & FreeBSD 4.0-RELEASE. The host is a 512MB :450MHz PIII, vmware is configured to use 64MB. : :If I run a synthetic program to apply memory pressure to the system, I :can lock the machine solid within minutes. :(app is ftp://ftp.cs.duke.edu/pub/gallatin/misc/hunt.c) : :Breaking into the debugger, I see this: : :db> ps : pid proc addr uid ppid pgrp flag stat wmesg wchan cmd : 359 d45f7520 d6dd1000 1387 321 359 004006 3 vmwait c02ce678 ahunt.x86 : 315 d45f7040 d6ddb000 1387 313 315 000106 3 inode c1880c00 vmware : 235 d45f8220 d6da2000 1387 234 235 004106 3 vmwait c02ce678 systat : 234 d45f7ee0 d6db6000 1387 216 234 004106 3 vmwait c02ce678 xterm : 99 d45f9dc0 d6d6a000 0 1 99 000004 3 vmwait c02ce678 ntpd : 22 d45fa100 d6d58000 0 1 22 000004 3 vmwait c02ce678 mount_mfs : 2 d45fac60 d4601000 0 0 0 100204 3 biord cbf00540 pagedaemon : 0 c02cb540 c0333000 0 0 0 000204 3 vmwait c02ce678 swapper : :db> show page :cnt.v_free_count: 345 :cnt.v_cache_count: 303 :... :cnt.v_free_reserved: 345 :cnt.v_free_min: 986 Ok, the system is low on pages, which accounts for the vmwait's The pagedaemon is stuck in biord, and that is definitely a problem. The question is: What mount point is that read coming off of? I suspect that the pagedaemon is trying to do a biord off the MFS filesystem and the MFS filesystem is locked up in vmwait. With the pagedaemon waiting for MFS and MFS waiting for free pages, the system winds up deadlocked. Can you try tracing out what mount that biord is operating on? And also what is the MFS process doing (traceback)? If that turns out to be it, try turning off the MFS filesystem and see if you can lock it up. :... : at ../../vm/vm_pager.h:145 :#10 0xc01ffe1d in vm_pageout_clean (m=0xc0ae7ff0) at ../../vm/vm_pageout.c:338 :#11 0xc020073e in vm_pageout_scan () at ../../vm/vm_pageout.c:914 :#12 0xc0201034 in vm_pageout () at ../../vm/vm_pageout.c:1350 :#13 0xc0231740 in fork_trampoline () : :Hmm.. why is it stuck there? : :------------------------------------------------------------------------------ :Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin :Duke University Email: gallatin@cs.duke.edu :Department of Computer Science Phone: (919) 660-6590 The pageout daemon assumes that it can page things out to vnodes. The problem is that I am guessing MFS needs some metadata (the biord the pageout daemon is stuck in) which it is trying to read in before being able to do the pageout. The pageout daemon is marked as being a special process and can eat into our free page reserve, but the MFS process is not (and generally can't be) marked that way. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-emulation" in the body of the message