Re: port-arm/38950: shark, hpcarm kernels prone to hard hangs on process exit

[Rafal Boni <rafal%pobox.com@localhost>]

The following reply was made to PR port-arm/38950; it has been noted by GNATS.

From: Rafal Boni <rafal%pobox.com@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: port-arm/38950: shark,
 hpcarm kernels prone to hard hangs on process exit
Date: Sat, 14 Jun 2008 01:10:53 -0400

 It looks like this is due to an overly agressive pmap optimization on 
 systems (like shark, hpcarm) that use low vectors and need the vector 
 page mapped into every pmap.
 
 Adding some debug code to the exit path (specifically in exit1()) makes 
 this 100% reproducible... a printf() after the uvm_proc_exit() in 
 exit1() causes the first user-space process which exits to reproducibly 
 wedge the system hard (and a following printf in uvm_lwp_hold() never 
 appears).  Unmapped/invalid vector page bad!
 
 The following change works around the issue for me and the system is now 
 happily (well, if you consider 90% system time happy.. that has to be a 
 top(1) bug... or maybe it's actually excessive pmap activity??) is 
 building pkgsrc packages.
 
 We still need a real fix based on this analysis, but at least this the 
 underlying issue (phew, it's not related to interrupt handling... or at 
 least only peripherally! ;)).
 
 --rafal
 
 Index: arm/arm32/pmap.c
 ===================================================================
 RCS file: /cvsroot/src/sys/arch/arm/arm32/pmap.c,v
 retrieving revision 1.176
 diff -u -p -r1.176 pmap.c
 --- arm/arm32/pmap.c    4 Jun 2008 12:41:40 -0000       1.176
 +++ arm/arm32/pmap.c    14 Jun 2008 04:52:54 -0000
 @@ -3798,8 +3798,10 @@ pmap_activate(struct lwp *l)
                  odacr = (DOMAIN_CLIENT << (PMAP_DOMAIN_KERNEL * 2)) |
                      (DOMAIN_CLIENT << (opm->pm_domain * 2));
 
 +#if 0
                  if (opm->pm_l1 == npm->pm_l1 && odacr == ndacr)
                          goto all_done;
 +#endif
          } else
                  opm = NULL;
 
 @@ -3861,7 +3865,9 @@ pmap_activate(struct lwp *l)
 
          block_userspace_access = 0;
 
 +#if 0
    all_done:
 +#endif
          /*
           * The new pmap is resident. Make sure it's marked
           * as resident in the cache/TLB.