Re: kernel page fault with nfs

From: John Baldwin <jhb_at_freebsd.org>
Date: Sat, 18 Oct 2014 06:43:58 -0400
On Friday, October 17, 2014 11:11:26 PM Tobias C. Berner wrote:
> Hi
> 
> 
> For some days now I've had problems with my current (last test with
> r273178M).
> 
> Sometimes when accessing a nfs-share there is a pagefault:
> 
> #######################################################
> Fatal trap 12: page fault while in kernel mode
> cpuid = 7; apic id = 07
> fault virtual address   = 0xfffffe07cfe60400
> fault code              = supervisor read data, page not present
> instruction pointer     = 0x20:0xffffffff80d4d4b6
> stack pointer           = 0x28:0xfffffe086088b380
> frame pointer           = 0x28:0xfffffe086088b3f0
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 43868 (mplayer)
> 
> 
> #0  0xffffffff80926d29 in shutdown_nice (howto=1) at
> /usr/src/sys/kern/kern_shutdown.c:207
> #1  0xffffffff80926a2d in kern_reboot (howto=260) at
> /usr/src/sys/kern/kern_shutdown.c:444
> #2  0xffffffff80926f80 in panic (fmt=0x104 <Address 0x104 out of bounds>) at
> /usr/src/sys/kern/kern_shutdown.c:698
> #3  0xffffffff8035f147 in panic_cmd_del (arg=0x0) at
> /usr/src/sys/ddb/db_command.c:244
> #4  0xffffffff8035ed5d in db_command (cmd_table=0x0) at
> /usr/src/sys/ddb/db_command.c:439
> #5  0xffffffff8035ead4 in db_command_loop () at
> /usr/src/sys/ddb/db_command.c:488 #6  0xffffffff803615e0 in db_trap
> (type=<value optimized out>, code=0) at /usr/src/sys/ddb/db_main.c:247
> #7  0xffffffff80966db1 in kdb_trap (type=12, code=0, tf=0xfffffe086088b2d0)
> at /usr/src/sys/kern/subr_kdb.c:626
> #8  0xffffffff80d4f92c in trap_fatal (frame=0xfffffe086088b2d0, eva=<value
> optimized out>) at /usr/src/sys/amd64/amd64/trap.c:835
> #9  0xffffffff80d4fcbc in trap_pfault (frame=0xfffffe086088b2d0, usermode=0)
> at atomic.h:161
> #10 0xffffffff80d4f2de in trap (frame=0xfffffe086088b2d0) at
> /usr/src/sys/amd64/amd64/trap.c:594
> #11 0xffffffff80d33822 in Xtss () at
> /usr/src/sys/amd64/amd64/exception.S:154 #12 0xffffffff80d4d4b6 in
> stack_save_td (st=<value optimized out>, td=<value optimized out>) at
> /usr/src/sys/amd64/amd64/stack_machdep.c:74
> #13 0xffffffff809f30b2 in foffset_unlock (fp=<value optimized out>,
> val=<value optimized out>, flags=<value optimized out>) at
> /usr/src/sys/kern/vfs_vnops.c:700
> #14 0xffffffff8082faad in ncl_bioread (vp=0xfffff80201dd7490,
> uio=0xfffffe086088b7d8, ioflag=<value optimized out>,
> cred=0xfffff8015816a600) at
> /usr/src/sys/fs/nfsclient/nfs_clbio.c:511
> #15 0xffffffff80e64381 in VOP_MARKATIME_APV (vop=<value optimized out>,
> a=0xfffffe086088b650) at vnode_if.c:856
> #16 0xffffffff809f4dd5 in vn_read (fp=0xfffff80272490cd0,
> uio=0xfffffe086088b7d8, active_cred=0xfffff8015816a600, flags=128,
> td=0xfffff80000000000) at vnode_if.h:859 #17 0xffffffff809f5502 in
> get_advice (fp=0xfffffe086088b730, uio=0x400) at
> /usr/src/sys/kern/vfs_vnops.c:729
> #18 0xffffffff809f2b80 in vn_io_fault1 () at
> /usr/src/sys/kern/vfs_vnops.c:1058 #19 0xffffffff809f0d3b in vn_io_fault
> (fp=0xfffff80272490cd0, uio=0xfffffe086088b970, active_cred=0x400,
> flags=128, td=0xfffff80000000000) at
> /usr/src/sys/kern/vfs_vnops.c:128
> #20 0xffffffff80981d95 in freebsd6_pread (td=0xfffff802d93204a8,
> uap=0xfffff9fb094c00a8) at /usr/src/sys/kern/sys_generic.c:217
> #21 0xffffffff80981ab8 in sys_cap_fcntls_get (td=<value optimized out>,
> uap=0x800) at /usr/src/sys/kern/sys_capability.c:576
> #22 0xffffffff80981a43 in sys_cap_fcntls_get (td=<value optimized out>,
> uap=0x0) at sx.h:183
> #23 0xffffffff80d503cb in amd64_syscall (td=0x45e400, traced=0) at
> subr_syscall.c:87
> #24 0xffffffff80d33b0b in Xprot () at
> /usr/src/sys/amd64/amd64/exception.S:324 #25 0x0000000806a7fe6a in ?? ()
> ##################################################

The functions in this stack trace don't make sense.  It is as if you are 
running kgdb against the wrong kernel.

-- 
John Baldwin
Received on Sat Oct 18 2014 - 09:56:52 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:53 UTC