port-evbppc/57926: ppc405: lockdebug crash because cpu_index(curcpu()) is invalid (not 0) value.

[hashikaw%mail.ru@localhost]

>Number:         57926
>Category:       port-evbppc
>Synopsis:       ppc405: lockdebug crash because cpu_index(curcpu()) is invalid (not 0) value.
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    port-evbppc-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Feb 11 16:45:00 +0000 2024
>Originator:     Kouichi Hashikawa
>Release:        10.0-RC3
>Organization:
>Environment:
>Description:
On OPENBLOCKS266(ppc405GPr) with LOCKDEBUG kernel,
kernel sometimes crash with mutex_vector_exit: not held by current CPU.
(or sometimes mutex_vector_enter,517: uninitialized lock...)

ddb shows following message, revalent CPU is cpu_index(curcpu()).
Why index is changed from 0??

Mutex error: mutex_vector_exit,730: not held by current CPU

[ 2261.9775931] lock address : 7f7ff98
[ 2261.9775931] type         : spin
[ 2261.9775931] initialized  : netbsd:sched_cpuattach+0x138
[ 2261.9775931] shared holds :                  0 exclusive:                  1
[ 2261.9775931] shares wanted:                  0 exclusive:                  0
[ 2261.9775931] relevant cpu :                187 last held:                  0
[ 2261.9775931] relevant lwp : 0x0000000001b30400 last held: 0x0000000007ef4940
[ 2261.9775931] last locked* : netbsd:softint_thread+0x14c
[ 2261.9775931] unlocked     : netbsd:mi_switch+0x190
[ 2261.9775931] owner field  : 000000000000000000 wait/spin:                0/1

[ 2261.9775931] panic: LOCKDEBUG: Mutex error: mutex_vector_exit,730: not held by current CPU
[ 2261.9775931] cpu187: Begin traceback...
[ 2261.9775931] 0x0086bdc0: at vpanic+0x160
[ 2261.9775931] 0x0086bdf0: at panic+0x58
[ 2261.9775931] 0x0086be30: at lockdebug_abort1+0x160
[ 2261.9775931] 0x0086be60: at mutex_exit+0x1e4
[ 2261.9775931] 0x0086be80: at mi_switch+0x18c
[ 2261.9775931] 0x0086bec0: at syscall+0x314
[ 2261.9775931] 0x0086bf20: user SC trap #3 by 0xfdbbc128: srr1=0xc030
[ 2261.9775931]             r1=0xfffeaff0 cr=0x44004242 xer=0 ctr=0xfdbbc120 esr=0x800000 pid=0xba

I examine 0x5e3580 (struct cpu_info), I got bb=187 as cpu_index(curcpu()).

db> x/bm 0x5e3580,256
netbsd:cpu_info:        00 00 00 bb 00 00 00 00 07 ef 4f 40 00 50 01 20         
..........O@.P.

'187' is ctx+1, that I got from 'machine ctx' on ddb.

db> show procs
PID    LID S CPU     FLAGS       STRUCT LWP *               NAME WAIT
19192>19192 7 187     40000            1b30400              nbawk
22446 22446 3 187       180            74db0c0             nbmake pipe_rd
18258 18258 3 187       180            74db3c0                 sh wait
db> mac ctx
process 0x23f56a8:pid:19192 pmap:0x6cd6c00 ctx:186 nbawk
process 0x23f4f28:pid:22446 pmap:0x7f67b00 ctx:181 nbmake
process 0x23f42a8:pid:18258 pmap:0x7f66e80 ctx:180 sh
process 0x23f51a8:pid:20474 pmap:0x6cd6fc0 ctx:115 nbmake

I cannot find why cpu_index(curcpu()) is overwitten...

>How-To-Repeat:

>Fix: