Support pmap_enter(..., psind=1) on i386

[alc]

Summary

The title says it all.

Test Plan

Ask Peter for help.

[alc]

Peter, could you please stress test this patch?

[kib]

Could you regenerate the patch with context, please ?

[alc]

Regenerate the diff with -U15.

[pho]

The only problem I came across was this:

panic: vm_fault_hold: fault on nofault entry, addr: 0x2871c000
cpuid = 0
time = 1531506262
KDB: stack backtrace:
db_trace_self_wrapper(1858e88,1ad15800,0,1ad15800,1d34f53c,...) at db_trace_self_wrapper+0x2a/frame 0x1d34f508
kdb_backtrace(18201b4,5b48ee56,0,1d34f5c4,e,...) at kdb_backtrace+0x2d/frame 0x1d34f570
vpanic(1804ff8,1d34f5c4,1d34f5c4,1d34f6a0,1465083,...) at vpanic+0x147/frame 0x1d34f5a4
panic(1804ff8,175ad3e,2871c000,1d34f60c,1d34f5fc,...) at panic+0x1b/frame 0x1d34f5b8
vm_fault_hold(2bc4000,2871c000,2,0,0,...) at vm_fault_hold+0x2b83/frame 0x1d34f6a0
vm_fault(2bc4000,2871c000,2,0,0,...) at vm_fault+0x5e/frame 0x1d34f6c8
trap_pfault(2871c664,1e812a14,1f2b6a80,1f2b6a80,0,...) at trap_pfault+0xfe/frame 0x1d34f710
trap(1d34f824,8,28,28,28e16840,...) at trap+0x40e/frame 0x1d34f818
calltrap() at PTDpde+0x6165/frame 0x1d34f818

• trap 0xc, eip = 0x1092305, esp = 0x1d34f864, ebp = 0x1d34f88c ---

funsetownlst(1a306cd0,0,173bb82,27d,1fce40a8,...) at funsetownlst+0x105/frame 0x1d34f88c
pgdelete(1a306cec,0,173bb82,26c,1a306cc0,...) at pgdelete+0x83/frame 0x1d34f8b4
leavepgrp(1fce4000,0,181fd66,37b,1f64e354,...) at leavepgrp+0x111/frame 0x1d34f8dc
proc_reap(1f2b6a80,1fce4000,1d34f9b4,36,1f2b6a80,...) at proc_reap+0x277/frame 0x1d34f908
proc_to_reap(7,0,0,1d34f9b4,36,...) at proc_to_reap+0x34c/frame 0x1d34f930
kern_wait6(1f2b6a80,7,0,0,1d34f9b4,...) at kern_wait6+0x251/frame 0x1d34f988
sys_wait4(1f2b6a80,1f2b6d04,1815f81,4,1d34fae8,...) at sys_wait4+0x87/frame 0x1d34faa8
syscall(1d34fba8,3b,3b,3b,0,...) at syscall+0x364/frame 0x1d34fb9c
Xint0x80_syscall() at PTDpde+0x63af/frame 0x1d34fb9c

I can not read the vmcore file.

Details: https://people.freebsd.org/~pho/stress/log/alc009.txt

[alc]

In D16246#344885, @pho wrote:

The only problem I came across was this:

panic: vm_fault_hold: fault on nofault entry, addr: 0x2871c000
cpuid = 0
time = 1531506262
KDB: stack backtrace:
db_trace_self_wrapper(1858e88,1ad15800,0,1ad15800,1d34f53c,...) at db_trace_self_wrapper+0x2a/frame 0x1d34f508
kdb_backtrace(18201b4,5b48ee56,0,1d34f5c4,e,...) at kdb_backtrace+0x2d/frame 0x1d34f570
vpanic(1804ff8,1d34f5c4,1d34f5c4,1d34f6a0,1465083,...) at vpanic+0x147/frame 0x1d34f5a4
panic(1804ff8,175ad3e,2871c000,1d34f60c,1d34f5fc,...) at panic+0x1b/frame 0x1d34f5b8
vm_fault_hold(2bc4000,2871c000,2,0,0,...) at vm_fault_hold+0x2b83/frame 0x1d34f6a0
vm_fault(2bc4000,2871c000,2,0,0,...) at vm_fault+0x5e/frame 0x1d34f6c8
trap_pfault(2871c664,1e812a14,1f2b6a80,1f2b6a80,0,...) at trap_pfault+0xfe/frame 0x1d34f710
trap(1d34f824,8,28,28,28e16840,...) at trap+0x40e/frame 0x1d34f818
calltrap() at PTDpde+0x6165/frame 0x1d34f818

• trap 0xc, eip = 0x1092305, esp = 0x1d34f864, ebp = 0x1d34f88c ---

funsetownlst(1a306cd0,0,173bb82,27d,1fce40a8,...) at funsetownlst+0x105/frame 0x1d34f88c
pgdelete(1a306cec,0,173bb82,26c,1a306cc0,...) at pgdelete+0x83/frame 0x1d34f8b4
leavepgrp(1fce4000,0,181fd66,37b,1f64e354,...) at leavepgrp+0x111/frame 0x1d34f8dc
proc_reap(1f2b6a80,1fce4000,1d34f9b4,36,1f2b6a80,...) at proc_reap+0x277/frame 0x1d34f908
proc_to_reap(7,0,0,1d34f9b4,36,...) at proc_to_reap+0x34c/frame 0x1d34f930
kern_wait6(1f2b6a80,7,0,0,1d34f9b4,...) at kern_wait6+0x251/frame 0x1d34f988
sys_wait4(1f2b6a80,1f2b6d04,1815f81,4,1d34fae8,...) at sys_wait4+0x87/frame 0x1d34faa8
syscall(1d34fba8,3b,3b,3b,0,...) at syscall+0x364/frame 0x1d34fb9c
Xint0x80_syscall() at PTDpde+0x63af/frame 0x1d34fb9c

I can not read the vmcore file.

Details: https://people.freebsd.org/~pho/stress/log/alc009.txt

Hmm, I'm not sure what to make of this. Is it reproducible?

[pho]

No, I have not been able to reproduce the panic: vm_fault_hold: fault on nofault entry.

[alc]

In D16246#345016, @pho wrote:

No, I have not been able to reproduce the panic: vm_fault_hold: fault on nofault entry.

All,

I'm inclined to commit the patch. Thoughts?

[kib]

In D16246#345077, @alc wrote:

In D16246#345016, @pho wrote:

No, I have not been able to reproduce the panic: vm_fault_hold: fault on nofault entry.

All,

I'm inclined to commit the patch. Thoughts?

I do not think that the reported panic is related to the patch. So go ahead.

[markj]

In D16246#344885, @pho wrote:

The only problem I came across was this:

panic: vm_fault_hold: fault on nofault entry, addr: 0x2871c000
cpuid = 0
time = 1531506262
KDB: stack backtrace:
db_trace_self_wrapper(1858e88,1ad15800,0,1ad15800,1d34f53c,...) at db_trace_self_wrapper+0x2a/frame 0x1d34f508
kdb_backtrace(18201b4,5b48ee56,0,1d34f5c4,e,...) at kdb_backtrace+0x2d/frame 0x1d34f570
vpanic(1804ff8,1d34f5c4,1d34f5c4,1d34f6a0,1465083,...) at vpanic+0x147/frame 0x1d34f5a4
panic(1804ff8,175ad3e,2871c000,1d34f60c,1d34f5fc,...) at panic+0x1b/frame 0x1d34f5b8
vm_fault_hold(2bc4000,2871c000,2,0,0,...) at vm_fault_hold+0x2b83/frame 0x1d34f6a0
vm_fault(2bc4000,2871c000,2,0,0,...) at vm_fault+0x5e/frame 0x1d34f6c8
trap_pfault(2871c664,1e812a14,1f2b6a80,1f2b6a80,0,...) at trap_pfault+0xfe/frame 0x1d34f710
trap(1d34f824,8,28,28,28e16840,...) at trap+0x40e/frame 0x1d34f818
calltrap() at PTDpde+0x6165/frame 0x1d34f818

• trap 0xc, eip = 0x1092305, esp = 0x1d34f864, ebp = 0x1d34f88c ---

funsetownlst(1a306cd0,0,173bb82,27d,1fce40a8,...) at funsetownlst+0x105/frame 0x1d34f88c
pgdelete(1a306cec,0,173bb82,26c,1a306cc0,...) at pgdelete+0x83/frame 0x1d34f8b4
leavepgrp(1fce4000,0,181fd66,37b,1f64e354,...) at leavepgrp+0x111/frame 0x1d34f8dc
proc_reap(1f2b6a80,1fce4000,1d34f9b4,36,1f2b6a80,...) at proc_reap+0x277/frame 0x1d34f908
proc_to_reap(7,0,0,1d34f9b4,36,...) at proc_to_reap+0x34c/frame 0x1d34f930
kern_wait6(1f2b6a80,7,0,0,1d34f9b4,...) at kern_wait6+0x251/frame 0x1d34f988
sys_wait4(1f2b6a80,1f2b6d04,1815f81,4,1d34fae8,...) at sys_wait4+0x87/frame 0x1d34faa8
syscall(1d34fba8,3b,3b,3b,0,...) at syscall+0x364/frame 0x1d34fb9c
Xint0x80_syscall() at PTDpde+0x63af/frame 0x1d34fb9c

I can not read the vmcore file.

Details: https://people.freebsd.org/~pho/stress/log/alc009.txt

Peter, do you still have the kernel symbols+core dump from this? I see that kgdb 6.1 segfaulted
but we might have more luck with kgdb 8. I've seen a couple of panic reports (on amd64)
which look similar, and I'd like to try and figure out what's going on.

[pho]

I have uploaded the kernel + core to https://people.freebsd.org/~pho/kernel+vmcore.9-t2.txz