Subject: Re: pmap_unwire: wiring for pmap 0xfoo va 0xbar didn't change!
To: None <yamt@netbsd.org>
From: Chuck Silvers <chuq@chuq.com>
List: current-users
Date: 08/28/2005 08:11:13
--zx4FCpZtqtKETZ7O
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

hi,

the attached patch fixes this problem, by removing an optimization that would
incorrectly skip TLB flushes in some cases where a pmap mapping is replaced
with another mapping of the same page, but with different permissions.
skipping the TLB flush is incorrect if the new entry is supposed to be wired,
since a stale read-only entry that's supposed to be writable might cause
a fault which would replace the wired entry with a non-wired entry
(which is what causes the warning messages).  increasing the permissions
an entry is not a common occurance, so it doesn't seem worthwhile to
complicate the code with the optimization, thus the proposal to just
remove it rather than fix it.

any objections?

-Chuck


On Fri, Apr 29, 2005 at 02:30:44PM -0400, Chris Tribo wrote:
> While I was only seeing these infrequently, that is not the case  
> anymore.
> 
> ...
> Apr 29 14:25:32 atlantis last message repeated 46 times
> Apr 29 14:26:27 atlantis last message repeated 65 times
> Apr 29 14:26:28 atlantis /netbsd: pmap_unwire: wiring for pmap  
> 0xce3c9d48 va 0xbdbcd000 didn't change!
> Apr 29 14:26:29 atlantis last message repeated 2 times
> Apr 29 14:26:30 atlantis /netbsd: pmap_unwire: wiring for pmap  
> 0xd1d42130 va 0xbdbcd000 didn't change!
> Apr 29 14:26:31 atlantis last message repeated 3 times
> Apr 29 14:26:32 atlantis /netbsd: pmap_unwire: wiring for pmap  
> 0xd1d420cc va 0xbdbcd000 didn't change!
> Apr 29 14:26:55 atlantis last message repeated 30 times
> Apr 29 14:26:55 atlantis /netbsd: pmap_unwire: wiring for pmap  
> 0xd1d42068 va 0xbdbcd000 didn't change!
> Apr 29 14:27:25 atlantis last message repeated 39 times
> ...
> 
> It's up to about once a second during compilation of some packages.
> 
> NetBSD atlantis 3.99.3 NetBSD 3.99.3 (GENERIC.MPACPI.DEBUG) #11: Thu  
> Apr 28 19:17:26 EDT 2005 
>  

--zx4FCpZtqtKETZ7O
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="diff.x86pmap.4"

Index: src/sys/arch/i386/i386/pmap.c
===================================================================
RCS file: /cvsroot/src/sys/arch/i386/i386/pmap.c,v
retrieving revision 1.184
diff -u -p -r1.184 pmap.c
--- src/sys/arch/i386/i386/pmap.c	12 Aug 2005 10:04:24 -0000	1.184
+++ src/sys/arch/i386/i386/pmap.c	28 Aug 2005 15:10:39 -0000
@@ -3297,21 +3297,6 @@ pmap_enter(pmap, va, pa, prot, flags)
 		opte = x86_atomic_testset_ul(ptep, npte);
 
 		/*
-		 * Any change in the protection level that the CPU
-		 * should know about ? 
-		 */
-		if ((npte & PG_RW)
-		     || ((opte & (PG_M | PG_RW)) != (PG_M | PG_RW))) {
-			/*
-			 * No need to flush the TLB.
-			 * Just add old PG_M, ... flags in new entry.
-			 */
-			x86_atomic_setbits_l(ptep, opte & (PG_M | PG_U));
-			goto out_ok;
-		}
-
-		/*
-		 * Might be cached in the TLB as being writable
 		 * if this is on the PVLIST, sync R/M bit
 		 */
 		if (opte & PG_PVLIST) {
@@ -3436,7 +3421,6 @@ shootdown_now:
 #endif
 	}
 
-out_ok:
 	error = 0;
 
 out:

--zx4FCpZtqtKETZ7O--