From owner-freebsd-current Mon Apr 29 5:58:13 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 8462E37B428 for ; Mon, 29 Apr 2002 05:57:39 -0700 (PDT) Received: (qmail 8400 invoked from network); 29 Apr 2002 12:57:38 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 29 Apr 2002 12:57:38 -0000 Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g3TCvbv26474; Mon, 29 Apr 2002 08:57:37 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 29 Apr 2002 08:56:51 -0400 (EDT) From: John Baldwin To: Robert Watson Subject: Re: page fault in _mtx_lock_flags Cc: jeff@FreeBSD.org, current@FreeBSD.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 29-Apr-2002 Robert Watson wrote: > > If I apply the attached diff to the kern_malloc.c, backing out a portion > of kern_malloc.c:1.99, the rate of panics plummets. Previously, I could > have a box panic within five minutes of getting the crash boxes spinning. > Now I've been going for about 40 minutes without any perceived failures > (i.e., no panics). I have no idea why this fixes the problem, but David > Wolfskill pointed me at that particular revision as being a source of > related problems for him. I'm going to leave the boxes running overnight > and see what I bump into. It would be nice to know if this is masking the > problem, or fixing the problem, and if so, why. You have memory corruption it looks like. I think the patch adds new buckets of larger sizes. Perhaps the problem is a bug in uma where someone allocates something bigger than the largest bucket, and the chunk they get back is only the size of an item in the largest bucket, thus when the code writes to the end of the structure it is overwriting other memory. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message