Page MenuHomeFreeBSD

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

Authored by alc on Jul 12 2018, 3:49 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Nov 13, 7:15 PM
Unknown Object (File)
Mon, Nov 11, 6:23 PM
Unknown Object (File)
Tue, Nov 5, 2:32 PM
Unknown Object (File)
Tue, Nov 5, 2:04 AM
Unknown Object (File)
Mon, Nov 4, 4:13 PM
Unknown Object (File)
Thu, Oct 31, 10:58 AM
Unknown Object (File)
Oct 23 2024, 12:56 PM
Unknown Object (File)
Oct 23 2024, 12:56 PM

Details

Summary

The title says it all.

Test Plan

Ask Peter for help.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Peter, could you please stress test this patch?

Could you regenerate the patch with context, please ?

Regenerate the diff with -U15.

This revision is now accepted and ready to land.Jul 12 2018, 5:35 PM

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

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?

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

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?

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.

This revision was automatically updated to reflect the committed changes.
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.