[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: port-arm/38950: shark, hpcarm kernels prone to hard hangs on process exit
The following reply was made to PR port-arm/38950; it has been noted by GNATS.
From: Rafal Boni <rafal%pobox.com@localhost>
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! ;)).
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 (opm->pm_l1 == npm->pm_l1 && odacr == ndacr)
opm = NULL;
@@ -3861,7 +3865,9 @@ pmap_activate(struct lwp *l)
block_userspace_access = 0;
* The new pmap is resident. Make sure it's marked
* as resident in the cache/TLB.
Main Index |
Thread Index |