[Bug 237718] head -r346588 (and later) for powerpc64 on PowerMac G5 exposes: mtx_lock of spin mutex WWV @ .../sys/powerpc/aim/mmu_oea64.c

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237718

            Bug ID: 237718
           Summary: head -r346588 (and later) for powerpc64 on PowerMac G5
                    exposes: mtx_lock of spin mutex WWV @
                    .../sys/powerpc/aim/mmu_oea64.c
           Product: Base System
           Version: CURRENT
          Hardware: powerpc
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs at FreeBSD.org
          Reporter: marklmi26-fbsd at yahoo.com

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.