>Number:         8480
>Category:       port-arm32
>Synopsis:       pmap_collect() implementation
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    port-arm32-maintainer (NetBSD/arm32 Portmaster)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Sep 23 06:50:00 1999
>Last-Modified:
>Originator:     Reinoud Zandijk
>Organization:
>Release:        NetBSD-release 11 sept 1999
>Environment:
RiscPC 600, ARM 710, 24 Mb, 2Mb VRAM.

System: NetBSD ismaelda 1.4.1 NetBSD 1.4.1 (config.ismaelda) #9: Sat Sep 18 01:56:36 CEST 1999 root@ismaelda:/usr/sources/release/src/sys/a
rch/arm32/compile/config.ismaelda arm32

>Description:
The function pmap_collect() wasn't implemented in arm32. Since some of the NetBSD/arm32 community
reported (including me) crashes under heavy load and some even reporting serious L1 page problems,
I decided to implement the function to release the L1/L2 page table preasure a bit.

I am reluctant to call it a fix to pr-8380, since pr-8380 looks more like a corrupt datastructure
problem to me; it should then have complained first about running out of L1/L2 pages...


>How-To-Repeat:
Without the patch, the machine crashes easily under heavy load/big programs. With the patch,
the system doesn't fall over that easy; mine never did anyway.


>Fix:
To fix, apply the following patch (note that it has to be cleaned up a bit....) :

"
*** /usr/src/sys/arch/arm32/arm32/pmap.c.orig   Fri Sep 17 21:09:22 1999
--- /usr/src/sys/arch/arm32/arm32/pmap.c        Sat Sep 18 00:28:36 1999
***************
*** 2736,2747 ****
--- 2736,2778 ----
   *
   * => optional function.
   * => called when a process is swapped out to free memory.
+  * 
+  * First tryout code; seems to work.....
   */
  
  void
  pmap_collect(pmap)
        pmap_t pmap;
  {
+       /* XXX PROPABLY BUGGY AS HELL */
+       PDEBUG(0, printf("pmap_collect : pmap = %p\n", pmap));
+ 
+       /*
+       /*
+        * Copied directly from mac68k. Maybe it's inefficient or plain
+        * wrong, but it's a start... only changed VM_MAX_ADDRESS to
+        * VM_MAXUSER_ADDRESS. This architecture seems to have a slightly
+        * different memory configuration -> using VM_MAX_ADDRESS freezes
+        * the machine.
+        */
+ 
+       if (pmap == pmap_kernel()) {
+               /* kernel mappings seem to be different / difficult; skipping for now */
+               PDEBUG(0, printf("pmap_collect : kernel pages, skipping\n"));
+               return;
+       } else {
+               /* 
+                * This process is about to be swapped out; free all of
+                * the PT pages by removing the physical mappings for its
+                * entire address space.  Note: pmap_remove() performs
+                * all necessary locking.
+                  */
+               pmap_remove(pmap, VM_MIN_ADDRESS, VM_MAXUSER_ADDRESS);
+       }
+ 
+ #if 0
+       /* Go compact and garbage-collect the pv_table. */
+       pmap_collect_pv();
+ #endif
  }
  
  /*
"


>Audit-Trail:
>Unformatted: