From Tor.Egge@idi.ntnu.no  Sun Apr  6 21:29:11 1997
Received: from who.cdrom.com (who.cdrom.com [204.216.27.3])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA17348
          for <FreeBSD-gnats-submit@freebsd.org>; Sun, 6 Apr 1997 21:29:11 -0700 (PDT)
Received: from pat.idt.unit.no (0@pat.idt.unit.no [129.241.103.5])
          by who.cdrom.com (8.8.5/8.6.11) with ESMTP id SAA27906
          for <FreeBSD-gnats-submit@freebsd.org>; Sun, 6 Apr 1997 18:32:24 -0700 (PDT)
Received: from presis.idt.ntnu.no (tegge@presis.idt.ntnu.no [129.241.111.173])
	by pat.idt.unit.no (8.8.5/8.8.5) with ESMTP id DAA13337
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 7 Apr 1997 03:32:16 +0200 (MET DST)
Received: (from tegge@localhost)
	by presis.idt.ntnu.no (8.8.5/8.8.5) id DAA03220;
	Mon, 7 Apr 1997 03:32:16 +0200 (MET DST)
Message-Id: <199704070132.DAA03220@presis.idt.ntnu.no>
Date: Mon, 7 Apr 1997 03:32:16 +0200 (MET DST)
From: Tor Egge <Tor.Egge@idi.ntnu.no>
Reply-To: Tor.Egge@idi.ntnu.no
To: FreeBSD-gnats-submit@freebsd.org
Subject: panic: pmap_zero_page: CMAP busy
X-Send-Pr-Version: 3.2

>Number:         3216
>Category:       kern
>Synopsis:       panic: pmap_zero_page: CMAP busy
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    tegge
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Apr  6 21:30:12 PDT 1997
>Closed-Date:    Thu Aug 10 13:40:41 PDT 2000
>Last-Modified:  Thu Aug 10 13:44:53 PDT 2000
>Originator:     Tor Egge
>Release:        FreeBSD 3.0-CURRENT i386
>Organization:
Norwegian University of Science and Technology, Trondheim, Norway
>Environment:

	FreeBSD-3.0 current as of Apr 6.

>Description:

while the processor is clearing pages in vm_page_zero_idle, interrupts are
enabled. This might cause an attempt to call pmap_zero_page while it
cannot be called.
	
db> trace
vget
ffs_sync
sync
boot
panic
pmap_zero_page    (probably via inlined vm_page_zero_fill) 
vm_fault
trap_pfault
trap
calltrap
trap 0xc, ...
ip_input
ipintr
swi_net_next
vm_page_zero_idle
idle_loop

>How-To-Repeat:

High system load, causing the queues of pages to be zero-filled to be long.
Then lower load, causing the idle_loop to be activated. Then a interrupt while
pmap_zero_page is using CMAP2.

>Fix:

Alternative 1:

Block some interrupts during the call to pmap_zero_page in vm_page_zero_idle.

*** vm_machdep.c.orig	Mon Apr  7 02:34:29 1997
--- vm_machdep.c	Mon Apr  7 03:07:49 1997
***************
*** 883,889 ****
--- 883,891 ----
  		--(*vm_page_queues[m->queue].lcnt);
  		TAILQ_REMOVE(vm_page_queues[m->queue].pl, m, pageq);
  		splx(s);
+ 		(void)splvm();
  		pmap_zero_page(VM_PAGE_TO_PHYS(m));
+ 		splx(s);
  		(void)splvm();
  		m->queue = PQ_ZERO + m->pc;
  		++(*vm_page_queues[m->queue].lcnt);


Alternative 2:

Introduce a modified clone of pmap zero_page, using CMAP3/CADDR3 instead of
CMAP2/CADDR2, and call that clone in vm_page_zero_idle instead of the 
original.

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->tegge 
Responsible-Changed-By: johan 
Responsible-Changed-When: Thu Aug 10 11:54:06 PDT 2000 
Responsible-Changed-Why:  
Tor, you appied your patch in rev 1.82 of vm_machdep.c 
but left this PR open and I  guess only you know why :-) 

http://www.freebsd.org/cgi/query-pr.cgi?pr=3216 
State-Changed-From-To: open->closed 
State-Changed-By: johan 
State-Changed-When: Thu Aug 10 13:40:41 PDT 2000 
State-Changed-Why:  
According to Tor: 
The patch only hides the real problem and was backed out. 

But the problem might have been solved by one of the added 
spl*() protections around critical sections or checks for 
malloc returning 0. 

The panic has not been seen recently and this PR is considered 
timed-out. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=3216 
>Unformatted:
