From owner-freebsd-stable@FreeBSD.ORG Wed Dec 17 22:46:33 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CED116A4CE; Wed, 17 Dec 2003 22:46:33 -0800 (PST) Received: from ftp.bjpu.edu.cn (ftp.bjpu.edu.cn [202.112.78.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id B91C943D31; Wed, 17 Dec 2003 22:46:31 -0800 (PST) (envelope-from delphij@frontfree.net) Received: by ftp.bjpu.edu.cn (Postfix, from userid 426) id F31CF52D3; Thu, 18 Dec 2003 14:46:28 +0800 (CST) Received: from srv (unknown [192.168.122.253]) by ftp.bjpu.edu.cn (Postfix) with ESMTP id C843C5299; Thu, 18 Dec 2003 14:46:28 +0800 (CST) From: "=?gb2312?B?WGluIExJL8Du9s4=?=" To: "'Doug White'" Date: Thu, 18 Dec 2003 14:46:28 +0800 Organization: Frontfree Technology Network MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 In-Reply-To: <20031217165012.K15803@carver.gumbysoft.com> Thread-Index: AcPFAgiEiPiz26M6T36z4zBggcDyRQAANr1Q Message-Id: <20031218064628.C843C5299@ftp.bjpu.edu.cn> cc: stable@FreeBSD.org cc: current@freebsd.org Subject: RE: [Backtrace] 4.9 and 5.1-RELEASE occasionly panic on RAM > 4GB without PAE (long) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2003 06:46:33 -0000 =20 > -----Original Message----- > From: Doug White [mailto:dwhite@gumbysoft.com]=20 > Sent: Thursday, December 18, 2003 8:58 AM > To: Xin LI/=C0=EE=F6=CE > Cc: stable@FreeBSD.org; current@freebsd.org > Subject: Re: [Backtrace] 4.9 and 5.1-RELEASE occasionly panic=20 > on RAM > 4GB without PAE (long) >=20 > PAE only has effect for >4GB (strictly), so exactly 4GB will=20 > work fine with !PAE. Oh... I am aware of this issue, however, only machines have RAM > 4GB = expose the problem. So I suspect that something has triggered the problem in = 4GB w/o PAE case. Because the system will not even boot into single user = mode under a PAE configuration, I was unable to provide any useful = information about the PAE case. I guess that there is some race condition inside the vm or pmap code. However, after a preliminary research on these code I did not found = problem. > Its probably due to poor tuning in this case. See the=20 > tuning(7) man page and innumerable mailing lists posts. =20 > Basically, you want to turn down maxusers (128 or so works=20 > best) and maybe change the kernel/user boundary and kmem=20 > sizes. vmstat -m is useful to keep track of kernel memory use. When we have removed some RAM, in other words, install 2GB memory on the box, the panic's goes away. Please note that the problem is not due to defective RAM chips as we have tested all possible combinations and the problem persists. >=20 > Also forkbombs (which is what your program is, effectively)=20 > are best controlled by using user resource limits. They're=20 > there for a reason. See the login.conf(5) man page. Oh... I think this is important, however, I got no reason why a server running ordinary service will cause panic when heavy load. Implementing a forkbomb is a Bad Idea(tm), but I will still argue that = our daily run and crashdumps shows that this panic is mostly fork-and-malloc related, so we have the test program, and it triggered similar panic as = we have. Because that our panic could not be easily to reproduce, and the = two panic's were so similiar, I think they might be the same problem. In addition, IMHO, a userland program should never cause a kernel-panic = if the kernel is implemented very well without any flaw. As I mentioned in = last letter, on a configuration having 2GB of RAM, the system seemed to be rock-solid. That's why I have the ugly proof code... > > panic: pmap_new_proc: u_map allocation failed >=20 > kmem exhaustion condition in -stable. Er... Is this problem only -STABLE related? Thanks! Xin LI