From owner-cvs-all@FreeBSD.ORG Sat Sep 20 14:30:27 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44FF116A4BF for ; Sat, 20 Sep 2003 14:30:27 -0700 (PDT) Received: from mail26d.sbc-webhosting.com (mail26d.sbc-webhosting.com [216.173.237.167]) by mx1.FreeBSD.org (Postfix) with SMTP id 04A4444008 for ; Sat, 20 Sep 2003 14:30:25 -0700 (PDT) (envelope-from alc@imimic.com) Received: from www.imimic.com (64.143.12.21)2-0942173422; Sat, 20 Sep 2003 17:30:22 -0400 (EDT) Sender: alc@FreeBSD.ORG Message-ID: <3F6CC6EF.52583B04@imimic.com> Date: Sat, 20 Sep 2003 16:30:23 -0500 From: "Alan L. Cox" Organization: iMimic Networking, Inc. X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jake Burkholder References: <200309201700.h8KH0xN0092997@repoman.freebsd.org> <3F6C9DD5.289EBC11@imimic.com> <20030920211524.GB15802@locore.ca> Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/sparc64/sparc64 pmap.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2003 21:30:27 -0000 X-List-Received-Date: Sat, 20 Sep 2003 21:30:27 -0000 Jake Burkholder wrote: > > Apparently, On Sat, Sep 20, 2003 at 01:35:01PM -0500, > Alan L. Cox said words to the effect of; > > > Jake Burkholder wrote: > > > > > > jake 2003/09/20 10:00:59 PDT > > > > > > FreeBSD src repository > > > > > > Modified files: > > > sys/sparc64/sparc64 pmap.c > > > Log: > > > Remove an invalid KASSERT. Apparently pmap_remove_all gets called on > > > unmanaged pages. > > > > > > Revision Changes Path > > > 1.124 +0 -3 src/sys/sparc64/sparc64/pmap.c > > > > FYI, this is, perhaps, triggered by a recent change that I made to > > kmem_malloc(), which declares the allocated pages as unmanaged. > > Ahh, ok, thanks, I wondered. The i386 pmap has similar assertions but > they seem to never be compiled. > In case it's not obvious, my rationale was to stop the creation of "pv" entries for kmem_map (including mbuf-related) pages. They serve no purpose. Regards, Alan P.S. In fact, I would argue that changing the type of the kernel and kmem vm objects to type PHYS would make a lot of sense. Today, it wouldn't have any functional effect, but it better describes the kind of object they are.