Bug 237718

head -r346588 accidentally added use of cmpb that is not
supported on old PPC970's, such as on old PowerMac G5s.

This turns out to provide a good test case for the handling
of such invalid instruction encodings and it exposed a
locking problem reported by the debug kernel.

I used https://artifact.ci.freebsd.org/snapshot/head/r346589/powerpc/powerpc64/
and some later ones in testing something else and ran into the issue
below. (-r346588 was not present for powerpc64.) The below is from a
later one:

panic: mtx_lock of spin mutex WWV @ /mnt/usr/src/sys/powerpc/aim/mmu_oea64.c:2812

For reference, line 2812 is: PMAP_LOCK(pm);

panic is reached via the following call chain,
shown as part of a backtrace (typed from screen
pictures):

.__mtx_lock_flags+0xd4
.moea64_sync_icache+0x48
.pmap_sync_icache+0x90
.ppc_instr_emulate+0x1b4
.trap+0x10fc
.powerpc_interrupt+0x2cc
user PGM trap by 0x810053bb4: srr1=0x900000000008d032
r1=0x3ffffffffffffcc00 cr=0x20002024 xer=0 ctr=0x1 r2=0x81007bdd0 frame=0xe000000070ca9810

It was thread pid 28 tid 100097

Actually r346589 was at line :2811 and had the following differences:

.ppc_intr_emulate+0x19c
.trap+0x1004

frame=0xe000000070ca9848


I will note that -r346670 has notes on the lists for running into:

mtx_lock of spin mutex(null) in .../kern/subr_bus.c:620

and being isolated by a bisect for being the first exposure in
that context.

This was not a powerpc64 context and may be completely unrelated.
But folks seemed confused about how -r346670 might lead to such
a panic.