[johnnym]

Looks like I never posted that I found a fix/workaround for the problem with the IP28 kernel in OpenBSD/sgi 7.2:

Well, my "solution" was to extend an existing - i.e still existing in OpenBSD/sgi - clause meant for R5000 and R7000 processors in sys/arch/mips64/include/pmap.h to also trigger for IP28 (i.e. CPU_R10000 and TGT_INDIGO2):

Code:

diff --git a/sys/arch/mips64/include/pmap.h b/sys/arch/mips64/include/pmap.h
index 7cbac309a96..391e542797c 100644
--- a/sys/arch/mips64/include/pmap.h
+++ b/sys/arch/mips64/include/pmap.h
@@ -177,8 +177,11 @@ void    pmap_page_cache(vm_page_t, u_int);
  * and many structures containing fields which will be used with
  * <machine/atomic.h> routines are allocated from pools, __HAVE_PMAP_DIRECT can
  * not be defined on systems which may use flawed processors.
+ *
+ * There could be a similar problem for the IP28 aka POWER Indigo2 R10000, so
+ * we exclude the definition of __HAVE_PMAP_DIRECT for these systems, too.
  */
-#if !defined(CPU_R5000) && !defined(CPU_RM7000)
+#if !( defined(CPU_R5000) || defined(CPU_RM7000) || ( defined(TGT_INDIGO2) && defined(CPU_R10000) ) )
#define    __HAVE_PMAP_DIRECT
vaddr_t    pmap_map_direct(vm_page_t);
vm_page_t pmap_unmap_direct(vaddr_t);

...and which prevents the definition of __HAVE_PMAP_DIRECT which leads to the described problems on IP28 with commit ae6cd46 in sgi-never-retired branch (d600f90 in the official OpenBSD source code).

The corresponding issue on GitHub was updated accordingly, as was the IP28 kernel of OpenBSD/sgi 7.2 on GitHub.