Page MenuHomeFreeBSD

pho (Peter Holm)
User

Projects

User Details

User Since
Aug 6 2014, 5:32 AM (266 w, 6 d)

Recent Activity

Fri, Sep 6

pho added a comment to D20664: Changes to vm_map_lookup_entry.

Tested D20664.61715.diff for 6 hours on amd64. No problems seen.

Fri, Sep 6, 3:19 PM

Wed, Sep 4

pho added a comment to D20664: Changes to vm_map_lookup_entry.

I ran a brief 10 hour test on amd64 with D20664.61638.diff. No problems seen.

Wed, Sep 4, 5:36 PM

Tue, Sep 3

pho committed rS351738: Disable core dumps..
Disable core dumps.
Tue, Sep 3, 7:09 AM
pho committed rS351736: Added problem found..
Added problem found.
Tue, Sep 3, 7:02 AM

Mon, Sep 2

pho added a comment to D17599: Fix for double free when deleting entries from epoch managed lists.

It is still an issue with HEAD:

:
:
if_delmulti_locked: detaching ifnet instance 0xfffff803d7598000
if_delmulti_locked: detaching ifnet instance 0xfffff803d7598000
if_delmulti_locked: detaching ifnet instance 0xfffff803bc652800
if_delmulti_locked: detaching ifnet instance 0xfffff803bc652800
if_delmulti_locked: detaching ifnet instance 0xfffff803bc652800
if_delmulti_locked: detaching ifnet instance 0xfffff803bc652800
if_delmulti_locked: detaching ifnet instance 0xfffff803bc652800
if_delmulti_locked: detaching ifnet instance 0xfffff803bc652800
Mon, Sep 2, 3:21 PM
pho committed rS351689: Added a new nullfs test scenario..
Added a new nullfs test scenario.
Mon, Sep 2, 8:03 AM
pho committed rS351688: Added a new tmpfs test scenario..
Added a new tmpfs test scenario.
Mon, Sep 2, 8:01 AM
pho committed rS351687: Added finding. Limit load and runtime..
Added finding. Limit load and runtime.
Mon, Sep 2, 7:59 AM
pho committed rS351686: Added a regression test..
Added a regression test.
Mon, Sep 2, 7:56 AM
pho committed rS351685: Added two more SCTP test case variations..
Added two more SCTP test case variations.
Mon, Sep 2, 7:54 AM
pho committed rS351684: Added "Fixed by". Pointed out problem with an uninitialized "flags".
Added "Fixed by". Pointed out problem with an uninitialized "flags"
Mon, Sep 2, 7:53 AM

Sun, Sep 1

pho added a comment to D21471: vfs: implement usecount implies holdcnt.

I ran the full stress2 test suite with D21471.61489.diff on amd64. No problems seen.

Sun, Sep 1, 11:06 PM

Thu, Aug 29

pho committed rS351602: Added regression tests..
Added regression tests.
Thu, Aug 29, 9:29 AM

Wed, Aug 28

pho added a comment to D21412: Rework v_object lifecycle for vnodes..

I ran a full stress2 test on i386 with D21412.61303.diff.
I ran tests on amd64 with D21412.61396.diff for two hours.
No problems seen.

Wed, Aug 28, 9:00 PM

Tue, Aug 27

pho added a comment to D21412: Rework v_object lifecycle for vnodes..
In D21412#466484, @kib wrote:

Peter, could you, please, start testing this ?

Tue, Aug 27, 2:44 PM

Sun, Aug 25

pho added a comment to D20814: Make entry simplification one-way.

I ran the full stress2 test with D20814.61081.diff on amd64. LGTM.

Sun, Aug 25, 7:00 AM
pho added a comment to D21357: Move OBJT_VNODE specific code from vm_object_terminate() to vnode_destroy_vobject()..

I ran all of the stress2 tests with D21357.61095.diff on amd64. LGTM.

Sun, Aug 25, 6:49 AM

Fri, Aug 23

pho committed rS351414: Added a test scenario for "recovering from disk failures"..
Added a test scenario for "recovering from disk failures".
Fri, Aug 23, 5:04 AM
pho added a comment to D20814: Make entry simplification one-way.

I should be able to free up some test hardware later today.

Fri, Aug 23, 4:58 AM

Wed, Aug 21

pho added a comment to D21320: amd64: rework PCPU allocation.

I ran a brief 2 hour test with D21320.61033.diff. No problems seen.

Wed, Aug 21, 6:35 PM

Aug 16 2019

pho added a comment to D13671: Collection of fixes for OOM handling of some corner cases..

D13671.60851.diff LGTM.

Aug 16 2019, 8:30 AM

Aug 3 2019

pho added a comment to D20863: prototype for trimming.

I ran tests on D20863.60414.diff for 6 hours and got this ktr log.

Aug 3 2019, 1:03 PM

Aug 1 2019

pho added a comment to D20814: Make entry simplification one-way.

I ran tests for 15 hours on D20814.60344.diff without seeing any problems.

Aug 1 2019, 6:57 PM
pho added a comment to D20361: procdesc: fix reparenting when the debugger is attached.

I completed a full stress2 test on amd64 without seeing any problems.

Aug 1 2019, 3:19 AM

Jul 31 2019

pho added a comment to D20814: Make entry simplification one-way.

With D20814.60322.diff I got:

20190731 19:27:23 all (1/1): mmap10.sh
panic: vm_map_unwire: lookup failed
cpuid = 12
time = 1564594061
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00c96c5790
vpanic() at vpanic+0x19d/frame 0xfffffe00c96c57e0
panic() at panic+0x43/frame 0xfffffe00c96c5840
vm_map_wire_locked() at vm_map_wire_locked+0x69d/frame 0xfffffe00c96c5900
vm_map_wire() at vm_map_wire+0x40/frame 0xfffffe00c96c5930
kern_mlock() at kern_mlock+0x179/frame 0xfffffe00c96c5980
amd64_syscall() at amd64_syscall+0x2d6/frame 0xfffffe00c96c5ab0
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe00c96c5ab0

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

Jul 31 2019, 5:51 PM
pho added a comment to D20814: Make entry simplification one-way.

D20814.60315.diff

20190731 16:18:08 all (17/73): mmap10.sh
panic: Lock vm map (user) not exclusively locked @ ../../../vm/vm_map.c:3102
cpuid = 12
time = 1564582693
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00c7c80800
vpanic() at vpanic+0x19d/frame 0xfffffe00c7c80850
panic() at panic+0x43/frame 0xfffffe00c7c808b0
_sx_xunlock() at _sx_xunlock+0xab/frame 0xfffffe00c7c808d0
_vm_map_unlock() at _vm_map_unlock+0x75/frame 0xfffffe00c7c80900
vm_map_wire() at vm_map_wire+0x58/frame 0xfffffe00c7c80930
kern_mlock() at kern_mlock+0x179/frame 0xfffffe00c7c80980
amd64_syscall() at amd64_syscall+0x2d6/frame 0xfffffe00c7c80ab0

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

Jul 31 2019, 2:48 PM

Jul 30 2019

pho added a comment to D21088: Avoid conflicts with libc symbols in libthr jump table..

I ran all of the threaded tests from stress2 on amd64 with D21088.60283.diff.
No problems seen.

Jul 30 2019, 9:12 PM
pho added a comment to D20361: procdesc: fix reparenting when the debugger is attached.

Just a follow up. I'm currently testing your patch on amd64 where I have not yet seen any problems.

Jul 30 2019, 7:03 PM
pho added a comment to D20361: procdesc: fix reparenting when the debugger is attached.

I got this after a 5 hour test on i386, followed by a shutdown:

panic: vm_fault_hold: fault on nofault entry, addr: 0x83326000
cpuid = 0
time = 1564486041
KDB: stack backtrace:
db_trace_self_wrapper(e6666d,1bdcda4,0,23a17534,bd2eb1,...) at db_trace_self_wrapper+0x2a/frame 0x23a17508
kdb_backtrace(e,0,0,2b06100,2db5000,...) at kdb_backtrace+0x2e/frame 0x23a17568
vpanic(163709e,23a175b0,23a175b0,23a17680,12c2044,...) at vpanic+0x121/frame 0x23a17590
panic(163709e,158dad9,83326000,4895800,7000004,...) at panic+0x14/frame 0x23a175a4
vm_fault_hold(2db5000,83326000,2,0,0) at vm_fault_hold+0x2474/frame 0x23a17680
vm_fault(2db5000,83326000,2,0) at vm_fault+0x4a/frame 0x23a176a8
trap_pfault(8332680c) at trap_pfault+0xf3/frame 0x23a176f4
trap(23a177bc,8,28,28,83df8640,...) at trap+0x3c0/frame 0x23a177b0
calltrap() at 0xffc0316d/frame 0x23a177b0
--- trap 0xc, eip = 0xf7f255, esp = 0x23a177fc, ebp = 0x23a17814 ---
funsetownlst(27e5ea50) at funsetownlst+0xa5/frame 0x23a17814
pgdelete(27e5ea6c,23c00a80,1651842,36,23a178f8,...) at pgdelete+0x60/frame 0x23a17834
leavepgrp(298d46a8,0,1651842,396,44c,...) at leavepgrp+0xd5/frame 0x23a1784c
proc_reap(23c00a80,298d46a8,23a17ba4,36,1edeb50,...) at proc_reap+0x714/frame 0x23a178f8
proc_to_reap(23c00a80,298d46a8,7,0,0,...) at proc_to_reap+0x718/frame 0x23a17998
kern_wait6(23c00a80,7,0,0,23a17ba4,...) at kern_wait6+0x37a/frame 0x23a17a78
kern_wait(23c00a80,ffffffff,23a17ba4,36,0,...) at kern_wait+0x119/frame 0x23a17b80
sys_wait4(23c00a80,23c00d0c) at sys_wait4+0x68/frame 0x23a17c08
syscall(23a17ce8,3b,3b,3b,0,...) at syscall+0x304/frame 0x23a17cdc
Xint0x80_syscall() at 0xffc033b7/frame 0x23a17cdc

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

Jul 30 2019, 11:59 AM
pho added a comment to D20863: prototype for trimming.

Ran tests for another 23 hours on D20863.60217.diff. No problems seen.

Jul 30 2019, 5:43 AM

Jul 27 2019

pho added a comment to D20814: Make entry simplification one-way.

I tested D20814.60178.diff for 13 hours on amd64 without seeing any problems.

Jul 27 2019, 11:35 AM

Jul 25 2019

pho added a comment to D21027: Simplify handling of superpages in pmap_clear_modify().

The i386 tests finished with one further problem and an incomplete report: https://people.freebsd.org/~pho/stress/log/alc011.txt

Jul 25 2019, 4:10 AM

Jul 24 2019

pho added a comment to D21027: Simplify handling of superpages in pmap_clear_modify().

I finished the full stress2 tests on amd64 without any issues.

Jul 24 2019, 1:58 PM

Jul 22 2019

pho added a comment to D21027: Simplify handling of superpages in pmap_clear_modify().

Sure, happy to.

Jul 22 2019, 3:24 PM
pho added a comment to D20863: prototype for trimming.

https://people.freebsd.org/~pho/D20863.60019.ktr.txt.xz

Jul 22 2019, 3:18 PM
pho added a comment to D20863: prototype for trimming.

I ran tests on a GENERICish kernel for 12 hours without any issue, however a kernel build with "options KTR" does not compile:

Jul 22 2019, 8:15 AM
pho committed rS350208: Added a regression test..
Added a regression test.
Jul 22 2019, 7:20 AM

Jul 21 2019

pho added a comment to D20863: prototype for trimming.

I still see the panic with D20863.59987.diff:

Jul 21 2019, 5:43 PM
pho added a comment to D20814: Make entry simplification one-way.

I ran a brief 4 hour test with this patch.

Jul 21 2019, 3:59 PM
pho added a comment to D20947: Check and avoid overflow when incrementing fp->f_count in fget_unlocked() and fhold()..

I completed a full stress2 test with D20947.59944.diff on amd64. No problems seen.

Jul 21 2019, 9:48 AM
pho added a comment to D20863: prototype for trimming.

With D20863.59975.diff I got:

Jul 21 2019, 8:58 AM

Jul 18 2019

pho added a comment to D20833: factor out common wiring code.

A have completed a full stress2 test of D20833.59786.diff without seeing any problems.

Jul 18 2019, 5:20 AM

Jul 17 2019

pho added a comment to D20863: prototype for trimming.

I have completed a full stress2 test with D20863.59745.diff on amd64 without seeing any problems.

Jul 17 2019, 1:26 PM

Jul 15 2019

pho added a comment to D20863: prototype for trimming.

Some KTR output for a short test of D20863.59745.diff:
https://people.freebsd.org/~pho/stress/log/dougm051.txt

Jul 15 2019, 7:45 AM
pho added a comment to D20949: Two issues with casueword(9) update..

I tested D20949.59742.diff with all of the threaded tests I have, on i386. No problems seen.

Jul 15 2019, 6:10 AM

Jul 14 2019

pho added a comment to D20863: prototype for trimming.

With D20863.59728.diff I got:

Jul 14 2019, 7:35 AM

Jul 13 2019

pho added a comment to D20863: prototype for trimming.

With D20863.59658.diff I got:

Jul 13 2019, 11:46 AM

Jul 12 2019

pho added a comment to D20893: Fix a next_leaf bug.

I finished the full stress2 test of D20893.59605.diff without finding any problems.

Jul 12 2019, 6:43 PM

Jul 11 2019

pho added a comment to D20893: Fix a next_leaf bug.

The test has now run for 12 hours without any problems. I'll let the test run for the full ~48 hours.

Jul 11 2019, 6:08 AM

Jul 10 2019

pho added a comment to D20893: Fix a next_leaf bug.

As far as I can tell the "panic: freeing free block" was introduced by r349777 and this patch didn't fix that.
I have not observed any other problems while testing with D20893.59572.diff

Jul 10 2019, 4:19 PM
pho added a comment to D20893: Fix a next_leaf bug.

I have tested D20893.59572.diff on amd64 and briefly on i386.
I still see the "panic: freeing free block" on both a MEMGUARD and a GENERICish build.

Jul 10 2019, 11:59 AM

Jul 9 2019

pho committed rS349859: Tests must run as root. Clear last known test..
Tests must run as root. Clear last known test.
Jul 9 2019, 12:14 PM
pho added a comment to D20579: Remove limit on blist_alloc maxsize, allow bigger getswapspace allocations.

Looks like this patch is responsible for the panics I see.

20190709 11:56:55 all (1/1): sort.sh
swap_pager: out of swap space
swp_pager_getswapspace(32): failed
Jul  9 12:03:41 mercat1 kernel: pid 3581 (sort), jid 0, uid 0, was killed: out of swap space
Jul  9 12:03:42 mercat1 kernel: pid 3583 (sort), jid 0, uid 0, was killed: out of swap space
panic: freeing free block: ffffc0, size 16, mask 1
cpuid = 7
time = 1562666624
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe102d95b270
vpanic() at vpanic+0x19d/frame 0xfffffe102d95b2c0
panic() at panic+0x43/frame 0xfffffe102d95b320
blst_meta_free() at blst_meta_free+0x12b/frame 0xfffffe102d95b360
blst_meta_free() at blst_meta_free+0x102/frame 0xfffffe102d95b3a0
blst_meta_free() at blst_meta_free+0x102/frame 0xfffffe102d95b3e0
blst_meta_free() at blst_meta_free+0x102/frame 0xfffffe102d95b420
blst_meta_free() at blst_meta_free+0x102/frame 0xfffffe102d95b460
blist_free() at blist_free+0x2e/frame 0xfffffe102d95b480
swp_pager_freeswapspace() at swp_pager_freeswapspace+0x8a/frame 0xfffffe102d95b4a0
swp_pager_meta_free_all() at swp_pager_meta_free_all+0xbb/frame 0xfffffe102d95b4f0
swap_pager_dealloc() at swap_pager_dealloc+0x115/frame 0xfffffe102d95b510
vm_object_terminate() at vm_object_terminate+0x27b/frame 0xfffffe102d95b560
vm_object_deallocate() at vm_object_deallocate+0x412/frame 0xfffffe102d95b5c0
vm_map_process_deferred() at vm_map_process_deferred+0x7f/frame 0xfffffe102d95b5e0
vm_map_remove() at vm_map_remove+0xc6/frame 0xfffffe102d95b610
vmspace_exit() at vmspace_exit+0xd3/frame 0xfffffe102d95b650
exit1() at exit1+0x5ad/frame 0xfffffe102d95b6c0
sigexit() at sigexit+0xdaf/frame 0xfffffe102d95b9a0
postsig() at postsig+0x336/frame 0xfffffe102d95ba70
ast() at ast+0x4c7/frame 0xfffffe102d95bab0
doreti_ast() at doreti_ast+0x1f/frame 0x7fffffffded0
KDB: enter: panic
[ thread pid 3581 tid 100238 ]
Stopped at      kdb_enter+0x3b: movq    $0,kdb_why
db> x/s version
version:        FreeBSD 13.0-CURRENT #5 r349777: Tue Jul  9 11:37:16 CEST 2019\012    pho@mercat1.netperf.freebsd.org:/usr/src/sys/amd64/compile/MEMGUARD\012
db>

The same test works fine on r349776.

Jul 9 2019, 10:24 AM
pho added a comment to D20863: prototype for trimming.

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

Jul 9 2019, 9:35 AM
pho added a comment to D20772: Provide protection against starvation of the ll/sc loops when accessing userpace..
In D20772#452692, @kib wrote:

Thank you, Mark.
Peter, could you, please, run the tests one more time, hopefully this is the last.

Jul 9 2019, 7:29 AM
pho added a comment to D20863: prototype for trimming.

I'll try again and avoid a panic, but in the meantime here's some trace: https://people.freebsd.org/~pho/stress/log/dougm047.txt

Jul 9 2019, 6:26 AM

Jul 8 2019

pho added a comment to D20833: factor out common wiring code.

So, this is unrelated to D20833.

Jul 8 2019, 9:34 AM
pho added a comment to D20833: factor out common wiring code.

The obvious questions are:
Does this happen without the patch in place?
Does this happen before r349777?

Jul 8 2019, 8:29 AM
pho added a comment to D20833: factor out common wiring code.

Came across this panic:

Jul 8 2019, 5:50 AM

Jul 7 2019

pho added a comment to D20833: factor out common wiring code.

I ran tests for 5 hours on i386 with D20833.59496.diff. No problems seen.

Jul 7 2019, 12:48 PM
pho added a comment to D20833: factor out common wiring code.

I have started a brief test run on i386 with D20833.59496.diff.

Jul 7 2019, 9:13 AM

Jul 6 2019

pho added a comment to D20833: factor out common wiring code.

I tested D20833.59460.diff for 5 hours without seeing any problems.

Jul 6 2019, 12:25 PM

Jul 5 2019

pho added a comment to D20579: Remove limit on blist_alloc maxsize, allow bigger getswapspace allocations.

I have run tests on D20579.59404.diff (with the typo fixed) for 8 hours. This included a buildworld / installworld.

Jul 5 2019, 8:15 PM
pho added a comment to D20579: Remove limit on blist_alloc maxsize, allow bigger getswapspace allocations.
cc -c -O2 -pipe -fno-strict-aliasing  -g -nostdinc  -I. -I../../.. -I../../../contrib/ck/include -I../../../contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h    -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD  -MF.depend.subr_blist.o -MTsubr_blist.o -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include -fdebug-prefix-map=./x86=/usr/src/sys/x86/include -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-address-of-packed-member  -mno-aes -mno-avx  -std=iso9899:1999 -Werror  ../../../kern/subr_blist.c                                                                                                                                                
../../../kern/subr_blist.c:659:17: error: use of undeclared identifier 'BLIST_MAP_RADIX'
        if (maxcount % BLIST_MAP_RADIX != 0)
                       ^
1 error generated.
*** Error code 1
Jul 5 2019, 11:20 AM
pho added a comment to D20833: factor out common wiring code.

Ran a brief test (5 hours) on D20833.59430.diff. No problems seen.

Jul 5 2019, 11:11 AM
pho committed rS349761: Added a regression test..
Added a regression test.
Jul 5 2019, 6:53 AM
pho added a comment to D20635: release multiple swap blocks at a time in swp_pager_force_pagein.

I have run tests on D20635.59379.diff for 24 hours without seeing any problems.

Jul 5 2019, 5:12 AM

Jul 4 2019

pho added a comment to D20635: release multiple swap blocks at a time in swp_pager_force_pagein.
In D20635#451659, @alc wrote:

Peter, can you please retest this patch? I think that all of the open issues have been addressed.

Jul 4 2019, 6:52 PM

Jul 3 2019

pho added a comment to D20833: factor out common wiring code.

I ran tests on D20833.59317.diff for 14 hours. LGTM.

Jul 3 2019, 7:01 AM

Jul 2 2019

pho added a comment to D20664: Changes to vm_map_lookup_entry.

Yes, fetch doesn't work well. Try using wget, which recovers from closed connections.

Jul 2 2019, 8:11 PM
pho added a comment to D20833: factor out common wiring code.
Fatal trap 12: page fault while in kernel mode
cpuid = 0; current process		= 4000 (tmlock)
interrupt enabled, fault virtual address	= 0x20
stack pointer	        = 0x28:0xfffffe00ad822860
resume, IOPL = 0
current process		= 4002 (tmlock)
code segment		= base 0x0, limit 0xfffff, type 0x1b
code segment		= base 0x0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, long 1, def32 0, gran 1
trap number		= 12
panic: page fault
cpuid = 11
time = 1562057287
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00ac311520
vpanic() at vpanic+0x19d/frame 0xfffffe00ac311570
panic() at panic+0x43/frame 0xfffffe00ac3115d0
trap_fatal() at trap_fatal+0x39c/frame 0xfffffe00ac311630
trap_pfault() at trap_pfault+0x62/frame 0xfffffe00ac311680
trap() at trap+0x2b4/frame 0xfffffe00ac311790
calltrap() at calltrap+0x8/frame 0xfffffe00ac311790
--- trap 0xc, rip = 0xffffffff80f0db15, rsp = 0xfffffe00ac311860, rbp = 0xfffffe00ac311910 ---
vm_map_wire_locked() at vm_map_wire_locked+0x155/frame 0xfffffe00ac311910
vm_map_wire() at vm_map_wire+0x40/frame 0xfffffe00ac311940
kern_mlock() at kern_mlock+0x179/frame 0xfffffe00ac311990
amd64_syscall() at amd64_syscall+0x291/frame 0xfffffe00ac311ab0

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

Jul 2 2019, 8:57 AM
pho added a comment to D20635: release multiple swap blocks at a time in swp_pager_force_pagein.

I have completed the selected swap tests and continued to run random tests for a total of 13H30.
No problems seen.

Jul 2 2019, 7:29 AM

Jul 1 2019

pho added a comment to D20635: release multiple swap blocks at a time in swp_pager_force_pagein.

This version got me past the test that kept triggering problems. I'll run some more tests ...

Jul 1 2019, 6:36 PM
pho added a comment to D20635: release multiple swap blocks at a time in swp_pager_force_pagein.
20190701 18:36:41 all (5/10): swap5.sh
panic: swp_pager_force_pagein: Too many pages: 32
cpuid = 8
time = 1561999005
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00adc594c0
vpanic() at vpanic+0x19d/frame 0xfffffe00adc59510
panic() at panic+0x43/frame 0xfffffe00adc59570
swp_pager_force_pagein() at swp_pager_force_pagein+0x7f/frame 0xfffffe00adc596f0
swap_pager_swapoff_object() at swap_pager_swapoff_object+0xfe/frame 0xfffffe00adc59750
swap_pager_swapoff() at swap_pager_swapoff+0xf9/frame 0xfffffe00adc597d0
swapoff_one() at swapoff_one+0x15e/frame 0xfffffe00adc59820
sys_swapoff() at sys_swapoff+0x1d6/frame 0xfffffe00adc59990
amd64_syscall() at amd64_syscall+0x291/frame 0xfffffe00adc59ab0

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

Jul 1 2019, 5:00 PM
pho added a comment to D20635: release multiple swap blocks at a time in swp_pager_force_pagein.

I'll try Diff 59264.

Jul 1 2019, 4:04 PM
pho added a comment to D20635: release multiple swap blocks at a time in swp_pager_force_pagein.

D20635.59261.diff did not seem to fix the problem.

20190701 17:39:16 all (5/10): swap5.sh
Jul 1 2019, 4:03 PM
pho added a comment to D20635: release multiple swap blocks at a time in swp_pager_force_pagein.

With D20635.59244.diff I now see a deadlock:
https://people.freebsd.org/~pho/stress/log/dougm044.txt

Jul 1 2019, 9:38 AM
pho added a comment to D20814: Make entry simplification one-way.
20190701 07:18:49 all (2/70): mmap10.sh
panic: _vm_map_clip_start: invalid clip of entry 0xfffff801496d34d0
cpuid = 9
time = 1561958339
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00ad7307a0
vpanic() at vpanic+0x19d/frame 0xfffffe00ad7307f0
panic() at panic+0x43/frame 0xfffffe00ad730850
_vm_map_clip_start() at _vm_map_clip_start+0x81/frame 0xfffffe00ad730890
vm_map_unwire() at vm_map_unwire+0x350/frame 0xfffffe00ad730960
sys_munlockall() at sys_munlockall+0x71/frame 0xfffffe00ad730990
amd64_syscall() at amd64_syscall+0x291/frame 0xfffffe00ad730ab0
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe00ad730ab0

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

Jul 1 2019, 5:39 AM
pho committed rS349570: Add missing x bit to the script..
Add missing x bit to the script.
Jul 1 2019, 5:12 AM
pho committed rS349569: Added a regression test..
Added a regression test.
Jul 1 2019, 5:09 AM

Jun 30 2019

pho added a comment to D20664: Changes to vm_map_lookup_entry.

https://people.freebsd.org/~pho/vmcore.1136.gz
https://people.freebsd.org/~pho/src.1136.gz

Jun 30 2019, 7:55 PM
pho added a comment to D20635: release multiple swap blocks at a time in swp_pager_force_pagein.

With D20635.59216.diff I see:

20190630 11:39:48 all (5/10): swap5.sh
panic: swapoff: failed to locate 8036 swap blocks
cpuid = 2
time = 1561887597
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00ad6c26a0
vpanic() at vpanic+0x19d/frame 0xfffffe00ad6c26f0
panic() at panic+0x43/frame 0xfffffe00ad6c2750
swap_pager_swapoff() at swap_pager_swapoff+0x194/frame 0xfffffe00ad6c27d0
swapoff_one() at swapoff_one+0x15e/frame 0xfffffe00ad6c2820
sys_swapoff() at sys_swapoff+0x1d6/frame 0xfffffe00ad6c2990
amd64_syscall() at amd64_syscall+0x291/frame 0xfffffe00ad6c2ab0
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe00ad6c2ab0
--- syscall (424, FreeBSD ELF64, sys_swapoff), rip = 0x8002f88ca, rsp = 0x7fffffffe4c8, rbp = 0x7fffffffe5f0 ---
KDB: enter: panic
[ thread pid 15529 tid 100290 ]
Stopped at      kdb_enter+0x3b: movq    $0,kdb_why
db> x/s version
version:        FreeBSD 13.0-CURRENT #1 r349552M: Sun Jun 30 10:48:06 CEST 2019\012    pho@mercat1.netperf.freebsd.org:/usr/src/sys/amd64/compile/PHO\012
db>

The swap5.sh test scenario is a "Test with out of swap space" test using a 4g memory disk as swap.

Jun 30 2019, 10:56 AM
pho committed rS349553: Added a regression test..
Added a regression test.
Jun 30 2019, 6:44 AM
pho added a comment to D20772: Provide protection against starvation of the ll/sc loops when accessing userpace..

On i386 I ran a buildworld / installworld + random stress2 tests for a total of 10H30.
On amd64 I ran random stress2 test for 10H30.
No problems seen.

Jun 30 2019, 5:56 AM

Jun 29 2019

pho added a comment to D20635: release multiple swap blocks at a time in swp_pager_force_pagein.

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

Jun 29 2019, 8:32 PM
pho added a comment to D20635: release multiple swap blocks at a time in swp_pager_force_pagein.

I saw the same problem with Diff 59201. I building with Diff 59205 now.

Jun 29 2019, 7:26 PM
pho added a comment to D20784: Fix mutual exclusion in pipe_direct_write()..

I reproduced the problem and verified that this patch fixed the problems.
No other problems seen with this patch.

Jun 29 2019, 3:12 PM
pho added a comment to D20635: release multiple swap blocks at a time in swp_pager_force_pagein.

D20635.59149.diff seems to be looping in swapoff(8):
https://people.freebsd.org/~pho/stress/log/dougm041.txt

Jun 29 2019, 12:05 PM
pho committed rS349537: Fix two cut and paste errors..
Fix two cut and paste errors.
Jun 29 2019, 9:15 AM
pho added a comment to D20664: Changes to vm_map_lookup_entry.

D20664.59090.diff completed tests on amd64 without any problems seen.

Jun 29 2019, 1:49 AM

Jun 28 2019

pho added a comment to D20633: Does clip_start require entry simplification?.

I ran random tests for 3 hours with D20633.59145.diff.
No problems seen.

Jun 28 2019, 9:52 AM

Jun 27 2019

pho added a comment to D20664: Changes to vm_map_lookup_entry.

I got this strange one while testing on i386. Not sure if it's related to your patch.

Jun 27 2019, 12:38 PM
pho added a comment to D20772: Provide protection against starvation of the ll/sc loops when accessing userpace..

I ran all of the threaded tests I have, twice. I also did a buildworld / installworld. This on amd64.
I'll run some i386 tests once my test box is available.

Jun 27 2019, 10:59 AM

Jun 26 2019

pho added a comment to D20664: Changes to vm_map_lookup_entry.

This looks promising.
I ran tests on i386 for three hours and uptime for amd64 is 5 hours. I'll leave the amd64 tests running.

Jun 26 2019, 3:45 PM
pho added a comment to D20664: Changes to vm_map_lookup_entry.
(kgdb) bt
#0  doadump (textdump=0x0) at include/pcpu.h:246
#1  0xffffffff8049c4fb in db_dump (dummy=<value optimized out>, dummy3=<value optimized out>, dummy4=<value optimized out>) at ../../../ddb/db_command.c:575                                                                                                                                             
#2  0xffffffff8049c2c9 in db_command (cmd_table=<value optimized out>, dopager=0x0) at ../../../ddb/db_command.c:482
#3  0xffffffff804a1248 in db_script_exec (scriptname=<value optimized out>, warnifnotfound=<value optimized out>) at ../../../ddb/db_script.c:304
#4  0xffffffff8049c2c9 in db_command (cmd_table=<value optimized out>, dopager=0x1) at ../../../ddb/db_command.c:482
#5  0xffffffff8049c044 in db_command_loop () at ../../../ddb/db_command.c:535
#6  0xffffffff8049f1ef in db_trap (type=<value optimized out>, code=<value optimized out>) at ../../../ddb/db_main.c:252
#7  0xffffffff80c1384c in kdb_trap (type=0x3, code=0x0, tf=<value optimized out>) at ../../../kern/subr_kdb.c:692
#8  0xffffffff8109ec31 in trap (frame=0xfffffe00ad617cd0) at ../../../amd64/amd64/trap.c:621
#9  0xffffffff810776d5 in calltrap () at ../../../amd64/amd64/exception.S:232
#10 0xffffffff80c12f5b in kdb_enter (why=0xffffffff81333b87 "panic", msg=<value optimized out>) at include/cpufunc.h:65
#11 0xffffffff80bca7ea in vpanic (fmt=<value optimized out>, ap=<value optimized out>) at ../../../kern/kern_shutdown.c:894
#12 0xffffffff80bca563 in panic (fmt=<value optimized out>) at ../../../kern/kern_shutdown.c:832
#13 0xffffffff80f04b4a in vm_map_splay_split (map=0xfffff8000ae825a0, addr=0x3ad618460, length=0x20000000, out_llist=0x7fffffffffffffff, out_rlist=0xfffff8000ae825a0) at ../../../vm/vm_map.c:1085                                                                                                      
#14 0x7fffffffffffffff in ?? ()
#15 0x0000000600000001 in ?? ()
#16 0xfffff8000ae825a0 in ?? ()
#17 0x7fffffffffffffff in ?? ()
#18 0x0000000000000000 in ?? ()
Current language:  auto; currently minimal
(kgdb) f 13
#13 0xffffffff80f04b4a in vm_map_splay_split (map=0xfffff8000ae825a0, addr=0x3ad618460, length=0x20000000, out_llist=0x7fffffffffffffff, out_rlist=0xfffff8000ae825a0) at ../../../vm/vm_map.c:1085                                                                                                      
1085                            SPLAY_LEFT_STEP(root, y, rlist,
(kgdb) l
1080            root = map->root;
1081            while (root != NULL && root->max_free >= length) {
1082                    KASSERT(llist->end <= root->start && root->end <= rlist->start,
1083                        ("%s: root not within tree bounds", __func__));
1084                    if (addr < root->start) {
1085                            SPLAY_LEFT_STEP(root, y, rlist,
1086                                y->max_free >= length && addr < y->start);
1087                    } else if (addr >= root->end) {
1088                            SPLAY_RIGHT_STEP(root, y, llist,
1089                                y->max_free >= length && addr >= y->end);
(kgdb) info loc
max_free = 0xfffff8000aee1002
llist = 0xaad617f00
rlist = 0x7fffffffffffffff
root = 0xfffffe00ad618460
y = 0x0
(kgdb) p *map
$1 = {header = {prev = 0xffffffff81eaa140, next = 0xfffff8000aee1000, left = 0x0, right = 0xfffff8000aee1010, start = 0x0, end = 0xffffffff81eaa670, next_read = 0x0, max_free = 0x0, object = {vm_object = 0x0, sub_map = 0x0}, offset = 0x0, eflags = 0x0, protection = 0x0, max_protection = 0x0,     
    inheritance = 0x0, read_ahead = 0x0, wired_count = 0x63fc98, cred = 0xfffff80003683f00, wiring_thread = 0xffffffff81e889a8}, lock = {lock_object = {lo_name = 0x0, lo_flags = 0x0, lo_data = 0x0, lo_witness = 0xfffff80006118880}, sx_lock = 0xfffff8000611b480}, system_mtx = {lock_object = {     
      lo_name = 0xfffff8000a9ff758 "", lo_flags = 0x6073700, lo_data = 0xfffff800, lo_witness = 0x18793}, mtx_lock = 0x0}, nentries = 0x0, size = 0x0, timestamp = 0x0, needs_wakeup = 0x0, system_map = 0x0, flags = 0x0, root = 0x0, pmap = 0x0, anon_loc = 0x0, busy = 0xae82678}                     
(kgdb)
Jun 26 2019, 7:51 AM
pho added a comment to D20664: Changes to vm_map_lookup_entry.

i386 booted with this patch.
On amd64 I got:

20190626 08:28:23 all (220/636): beneath.sh
Fatal double fault
rip 0xffffffff80ef9584 rsp 0xfffffe00a7c00f80 rbp 0xfffffe00a7c010b0
rax 0xfffff80397d07000 rdx 0x1 rbx 0
rcx 0 rsi 0xfffff803e0c70000 rdi 0
r8 0 r9 0xfffffe00a7c014f8 r10 0xfffffe00a7c014cc
r11 0xfffffe00a7c01527 r12 0x1 r13 0xfffff803979ae000
r14 0 r15 0xfffff803e0c70000 rflags 0x10282
cs 0x20 ss 0x28 ds 0x3b es 0x3b fs 0x13 gs 0x1b
fsbase 0x8002438d0 gsbase 0xffffffff820c7480 kgsbase 0
cpuid = 9; apic id = 09
panic: double fault
cpuid = 9
time = 1561530504
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0006bd1db0
vpanic() at vpanic+0x19d/frame 0xfffffe0006bd1e00
panic() at panic+0x43/frame 0xfffffe0006bd1e60
dblfault_handler() at dblfault_handler+0x1de/frame 0xfffffe0006bd1f30
Xdblfault() at Xdblfault+0xc3/frame 0xfffffe0006bd1f30
--- trap 0x17, rip = 0xffffffff80ef9584, rsp = 0xfffffe00a7c00f80, rbp = 0xfffffe00a7c010b0 ---
vm_fault_hold() at vm_fault_hold+0x14/frame 0xfffffe00a7c010b0
vm_fault() at vm_fault+0x60/frame 0xfffffe00a7c010f0
trap_pfault() at trap_pfault+0x188/frame 0xfffffe00a7c01140
trap() at trap+0x2b4/frame 0xfffffe00a7c01250
calltrap() at calltrap+0x8/frame 0xfffffe00a7c01250
--- trap 0xc, rip = 0xffffffff80f06a14, rsp = 0xfffffe00a7c01320, rbp = 0xfffffe00a7c01400 ---
vm_map_lookup() at vm_map_lookup+0x294/frame 0xfffffe00a7c01400
vm_fault_hold() at vm_fault_hold+0x80/frame 0xfffffe00a7c01550
vm_fault() at vm_fault+0x60/frame 0xfffffe00a7c01590
trap_pfault() at trap_pfault+0x188/frame 0xfffffe00a7c015e0
trap() at trap+0x2b4/frame 0xfffffe00a7c016f0
calltrap() at calltrap+0x8/frame 0xfffffe00a7c016f0
--- trap 0xc, rip = 0x7ffffffcb001, rsp = 0xfffffe00a7c017c0, rbp = 0xfffffe00a7c01988 ---
??() at 0x7ffffffcb001/frame 0xfffffe00a7c01988
??() at 0xfffff803e0c70000/frame 0xffffffff820be480
??() at 0xfffff800036bf000/frame 0xfffff800036bf000
??() at 0xfffff800036b7000/frame 0xffffffff81ea54c0
ll() at 0xb0000/frame 0xffffffff81ea6138
KDB: enter: panic
[ thread pid 19330 tid 100497 ]
Stopped at      kdb_enter+0x3b: movq    $0,kdb_why
db>

https://people.freebsd.org/~pho/stress/log/dougm039.txt
I'll retry with vm_map.c compiled with '-O0' for more debug info.

Jun 26 2019, 7:32 AM
pho added a comment to D20664: Changes to vm_map_lookup_entry.

This is what I see on i386:

uhub3: 2 ports with 2 removable, self powered
uhub5: 2 ports with 2 removable, self powered
panic: Bad entry start/end for new stack entry
cpuid = 3
time = 1561525410
KDB: stack backtrace:
db_trace_self_wrapper(e64bdd,1bd0e18,0,1251889c,bd29a1,...) at db_trace_self_wrapper+0x2a/frame 0x12518870
kdb_backtrace(7,3,3,ffbdf000,ffbff000,...) at kdb_backtrace+0x2e/frame 0x125188d0
vpanic(162b7f6,12518918,12518918,1251893c,12bd2ec,...) at vpanic+0x121/frame 0x125188f8
panic(162b7f6,17fc10c0,17fc10c0,fbbff000,2104fbac,...) at panic+0x14/frame 0x1251890c
vm_map_stack_locked(4000000,20000,3,7,1000) at vm_map_stack_locked+0x19c/frame 0x1251893c
vm_map_stack(2104fbac,fbbff000,4000000,3,7,1000) at vm_map_stack+0x9e/frame 0x12518968
exec_new_vmspace(12518a98,1c2c880) at exec_new_vmspace+0x2f6/frame 0x125189c0
exec_elf32_imgact(12518a98) at exec_elf32_imgact+0x7f6/frame 0x12518a4c
kern_execve(99d9a80,12518c70,0) at kern_execve+0x546/frame 0x12518c44
start_init(0,12518ce8) at start_init+0x190/frame 0x12518cb4
fork_exit(f6e2d0,0,12518ce8,0,0,...) at fork_exit+0x6c/frame 0x12518cd4
fork_trampoline() at 0xffc033ca/frame 0x12518cd4
--- trap 0, eip = 0, esp = 0x12518d20, ebp = 0 ---
(null)() at 0
KDB: enter: panic
[ thread pid 1 tid 100002 ]
Stopped at      kdb_enter+0x35: movl    $0,kdb_why
db> x/s version
version:        FreeBSD 13.0-CURRENT #0 r349393: Wed Jun 26 06:46:30 CEST 2019\012    pho@x4.osted.lan:/usr/src/sys/i386/compile/PHO\012
db>
Jun 26 2019, 5:31 AM

Jun 24 2019

pho added a comment to D20711: Stop early clipping in vm_map_protect.

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

Jun 24 2019, 5:21 AM
pho added a comment to D20711: Stop early clipping in vm_map_protect.

With D20711.58934.diff I get:

20190624 05:49:07 all (2/15): mmap11.sh
panic: vm_map_protect: wrong amount reserved
cpuid = 1
time = 1561348157
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00aca04800
vpanic() at vpanic+0x19d/frame 0xfffffe00aca04850
panic() at panic+0x43/frame 0xfffffe00aca048b0
vm_map_protect() at vm_map_protect+0x7b9/frame 0xfffffe00aca04960
kern_mprotect() at kern_mprotect+0xc0/frame 0xfffffe00aca04990
amd64_syscall() at amd64_syscall+0x291/frame 0xfffffe00aca04ab0
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe00aca04ab0

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

Jun 24 2019, 4:04 AM

Jun 23 2019

pho added a comment to D20711: Stop early clipping in vm_map_protect.

Ah!
https://people.freebsd.org/~pho/stress/log/dougm036.txt is patched with D20711.58892.diff

Jun 23 2019, 8:00 AM