From owner-freebsd-current@FreeBSD.ORG Sun Oct 1 16:51:35 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6110716A416; Sun, 1 Oct 2006 16:51:35 +0000 (UTC) (envelope-from mb@imp.ch) Received: from pop.imp.ch (mx2.imp.ch [157.161.9.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 225B043D49; Sun, 1 Oct 2006 16:51:30 +0000 (GMT) (envelope-from mb@imp.ch) Received: from godot.imp.ch (godot.imp.ch [157.161.4.8]) by pop.imp.ch (8.13.8/8.13.8/Submit_imp) with ESMTP id k91GpSRj078932; Sun, 1 Oct 2006 18:51:29 +0200 (CEST) (envelope-from mb@imp.ch) Date: Sun, 1 Oct 2006 18:51:28 +0200 (CEST) From: Martin Blapp To: current@freebsd.org In-Reply-To: <20061001132422.O91466@godot.imp.ch> Message-ID: <20061001183645.Y91466@godot.imp.ch> References: <20060928195536.Y91466@godot.imp.ch> <20061001132422.O91466@godot.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.57 on 157.161.9.65 Cc: alc@freebsd.org Subject: Re: CURRENT unusable again, too many panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Oct 2006 16:51:35 -0000 Ok, the commit has been identified. After Reverting this revision, my Box doesn't panic anymore. With this revision in place, my box panics 100% at startup doing vi.recover things. Revision 1.564 / Tue Jun 27 04:28:23 2006 UTC (3 months ago) by alc Branch: MAIN Changes since 1.563: +5 -3 lines Diff to previous 1.563 (colored) Correct a very old and very obscure bug: vmspace_fork() calls pmap_copy() if the mapping is VM_INHERIT_SHARE. Suppose the mapping is also wired. vmspace_fork() clears the wiring attributes in the vm map entry but pmap_copy() copies the PG_W attribute in the PTE. I don't think this is catastrophic. It blocks pmap_remove_pages() from destroying the mapping and corrupts the pmap's wiring count. This revision fixes the problem by changing pmap_copy() to clear the PG_W attribute. Reviewed by: tegge@