On 30/05/24(Thu) 13:11, Eric Grosse wrote:
> And, fairly quickly, another one. The load depends on what's in the Go
> team build queue, which is not under my control.To avoid further
> spamming the list I won't report any more of these until I can get
> something reproducible under my control. Of course, anyone interested
> may contact me directly if interested.
There's a corruption...
> ddb{7}> show panic
> cpu6: kernel diagnostic assertion "((flags & PGO_LOCKED) != 0 &&
> rw_lock_held(
> uobj->vmobjlock)) || (flags & PGO_LOCKED) == 0" failed: file
> "/sys/uvm/uvm_vnod
> e.c", line 953
>
> *cpu7: assertwaitok: non-zero mutex count: 1
> ddb{7}> trace
> panic+0x134
> assertwaitok+0xf8
> mi_switch+0x5c
> sleep_finish+0x160
> rw_enter+0x1cc
> vm_map_lock_read_ln+0x38
> uvmfault_lookup+0x114
> uvm_fault_check+0x68
> uvm_fault+0x12c
> trap+0x7a4
> trapagain+0x4
> --- trap (type 0x300) ---
> phtree_RBT_COMPARE+0x28
> pool_do_put+0x94
> pool_put+0x94
^^^^
...inside this pool. Which of the 3 is it? Can someone with a ppc64
figure out?
> pmap_vp_destroy+0xb0
> pmap_destroy+0x50
> uvm_map_teardown+0x248
> uvmspace_free+0x70
> uvm_exit+0x38
> reaper+0x168
> proc_trampoline+0x10
Does the corruption happen at the same place every time you see a panic?
