From owner-freebsd-current Thu Oct 28 20:13:36 1999 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id E1A8414D21 for ; Thu, 28 Oct 1999 20:13:32 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from p54-ts5.syd2.zeta.org.au (beefcake.zeta.org.au [203.26.10.12]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id NAA25169; Fri, 29 Oct 1999 13:17:53 +1000 Date: Fri, 29 Oct 1999 13:13:21 +1000 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Luoqi Chen Cc: current@FreeBSD.ORG, khetan@os.org.za Subject: Re: CMAP2 busy ? In-Reply-To: <199910282058.QAA28372@lor.watermarkgroup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 28 Oct 1999, Luoqi Chen wrote: > > ... > > panic: pmap_zero_page: CMAP2 busy > > > It looked like an interrupt hit when the cpu was in an idle loop replenishing > zero filled pages, and the interrupt handler somehow also tried to zero some > pages itself. In vm_page_zero_idle(), pmap_zero_page should be called > at splvm() to prevent this from happening, or allocate another pte exclusively > for the idle loop. The latter seems to be preferable. It is an error to use CMAP2 in an interrupt handler. CMAP2 is reserved for use in process and trap context. E.g., it is used in pmap_copy_page() which is often called from vm_fault() without any spl protection. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message