On Tue, 18 Nov 2014, Dmitry Morozovsky wrote:
> my backup server after updrade to frest stable/10
>
> start panicing on heavy disk load like rsync at
Yes, it is reproducible easy and now I'm at ddb prompt with
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0860864d60
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0860864e10
vpanic() at vpanic+0x126/frame 0xfffffe0860864e50
panic() at panic+0x43/frame 0xfffffe0860864eb0
vm_fault_hold() at vm_fault_hold+0x1932/frame 0xfffffe0860865100
vm_fault() at vm_fault+0x77/frame 0xfffffe0860865140
trap_pfault() at trap_pfault+0x201/frame 0xfffffe08608651e0
trap() at trap+0x47a/frame 0xfffffe08608653f0
calltrap() at calltrap+0x8/frame 0xfffffe08608653f0
--- trap 0xc, rip = 0xffffffff81b69d04, rsp = 0xfffffe08608654b0, rbp =
0xfffffe0860865500 ---
zap_leaf_lookup_closest() at zap_leaf_lookup_closest+0xb4/frame
0xfffffe0860865500
fzap_cursor_retrieve() at fzap_cursor_retrieve+0x16e/frame 0xfffffe0860865570
zap_cursor_retrieve() at zap_cursor_retrieve+0x1f7/frame 0xfffffe0860865600
zfs_freebsd_readdir() at zfs_freebsd_readdir+0x426/frame 0xfffffe0860865840
VOP_READDIR_APV() at VOP_READDIR_APV+0xa7/frame 0xfffffe0860865870
kern_getdirentries() at kern_getdirentries+0x21c/frame 0xfffffe0860865970
sys_getdirentries() at sys_getdirentries+0x28/frame 0xfffffe08608659a0
amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe0860865ab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0860865ab0
--- syscall (196, FreeBSD ELF64, sys_getdirentries), rip = 0x80091043a, rsp =
0x7fffffffb538, rbp = 0x7fffffffb560 ---
KDB: enter: panic
[ thread pid 1167 tid 100461 ]
Stopped at kdb_enter+0x3e: movq $0,kdb_why
db>
Can I obtain somthing useful from here? I'm afraid it's not easy to
attach
additional disk for crash dumps to this server...
>
> FreeBSD whale.rinet.ru 10.1-STABLE FreeBSD 10.1-STABLE #195 r274646: Tue
Nov 18
> 12:15:24 MSK 2014
> marck at castor.rinet.ru:/usr/obj/FreeBSD/pristine/src.10/sys/GENERIC
amd64
>
>
> panic: vm_fault: fault on nofault entry, addr: fffffe001805b000
> cpuid = 0
> KDB: stack backtrace:
> #0 0xffffffff80964fa0 at kdb_backtrace+0x60
> #1 0xffffffff8092a085 at panic+0x155
> #2 0xffffffff80ba168e at vm_fault_hold+0x1b6e
> #3 0xffffffff80b9fad7 at vm_fault+0x77
> #4 0xffffffff80d2861c at trap_pfault+0x19c
> #5 0xffffffff80d27dea at trap+0x47a
> #6 0xffffffff80d0db92 at calltrap+0x8
> #7 0xffffffff819df8ee at fzap_cursor_retrieve+0x16e
> #8 0xffffffff819e4c97 at zap_cursor_retrieve+0x1f7
> #9 0xffffffff81a1fed6 at zfs_freebsd_readdir+0x426
> #10 0xffffffff80e456b7 at VOP_READDIR_APV+0xa7
> #11 0xffffffff809d68cc at kern_getdirentries+0x21c
> #12 0xffffffff809d6688 at sys_getdirentries+0x28
> #13 0xffffffff80d28da1 at amd64_syscall+0x351
> #14 0xffffffff80d0de7b at Xfast_syscall+0xfb
> Uptime: 1m51s
>
> Unfortunately it's ZFS only, so I have no space to white panic dump.
>
> I'm now trying to rebuild kernel with debugger turned on, as luckily I
have
> working console at SOL...
>
> Any preliminary hints?
>
>
--
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer: marck at FreeBSD.org ]
------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru ***
------------------------------------------------------------------------