On 7/8/2013 2:06 AM, Christian Ehrhardt wrote:
Can you try to see if the following patch helps? It did for me, when
I was debugging a similar panic back in December. However, my
explanation why the patch would fix this bug, turned out to be invalid.
Still the bug went away. If the same happens for you, some more people
should have a look at the patch:
--- /mount/blink/aegis/project/gg/history/os/src/sys/arch/i386/i386/pmap.c
2012/10/16 18:31:28 1.117
+++ /mount/blink/aegis/project/gg/history/os/src/sys/arch/i386/i386/pmap.c
2013/01/24 17:20:06 1.118
@@ -495,7 +495,7 @@ pmap_map_ptes(struct pmap *pmap)
/* need to load a new alternate pt space into curpmap? */
opde = *APDP_PDE;
-#if defined(MULTIPROCESSOR) && defined(DIAGNOSTIC)
+#if defined(DIAGNOSTIC)
if (pmap_valid_entry(opde))
panic("pmap_map_ptes: APTE valid");
#endif
@@ -521,10 +521,8 @@ pmap_unmap_ptes(struct pmap *pmap)
if (pmap_is_curpmap(pmap)) {
simple_unlock(&pmap->pm_obj.vmobjlock);
} else {
-#if defined(MULTIPROCESSOR)
*APDP_PDE = 0;
pmap_apte_flush();
-#endif
simple_unlock(&pmap->pm_obj.vmobjlock);
simple_unlock(&curpcb->pcb_pmap->pm_obj.vmobjlock);
}
regards Christian
Hello Christian.
Yes, I can confirm that after applying your patch and rebuilding the
kernel, I was able to successfully build userland without a panic, after
all previous efforts consistently failed.
So, thank you!. And if there is anything I can do to help see that patch
merged into the source tree, please let me know.
Cheers.
- Scott
