Re: panic in sys_fstatat (?)

From: Eric van Gyzen <eric_at_vangyzen.net>
Date: Mon, 02 Feb 2015 13:29:45 -0500
On 02/02/2015 13:22, Steve Kargl wrote:
> On Mon, Feb 02, 2015 at 01:10:47PM -0500, Eric van Gyzen wrote:
>> On 02/02/2015 12:59, Steve Kargl wrote:
>>> (kgdb) #0  doadump (textdump=Unhandled dwarf expression opcode 0x93
>>> ) at pcpu.h:219
>>> #1  0xffffffff80559f47 in kern_reboot (howto=260)
>>>     at /usr/src/sys/kern/kern_shutdown.c:448
>>> #2  0xffffffff8055a3b0 in panic (fmt=<value optimized out>)
>>>     at /usr/src/sys/kern/kern_shutdown.c:747
>>> #3  0xffffffff807a85c0 in trap_fatal (frame=<value optimized out>, 
>>>     eva=<value optimized out>) at /usr/src/sys/amd64/amd64/trap.c:861
>>> #4  0xffffffff807a8221 in trap (frame=<value optimized out>)
>>>     at /usr/src/sys/amd64/amd64/trap.c:201
>>> #5  0xffffffff8078d843 in calltrap ()
>>>     at /usr/src/sys/amd64/amd64/exception.S:235
>>> #6  0xffffffff80754567 in ufs_getattr (ap=<value optimized out>)
>>>     at /usr/src/sys/ufs/ufs/ufs_vnops.c:463
>>> #7  0xffffffff808074fa in VOP_GETATTR_APV (vop=<value optimized out>, 
>>>     a=<value optimized out>) at vnode_if.c:731
>>> #8  0xffffffff80607e62 in vn_stat (vp=0xfffff80088086000, 
>>>     sb=0xfffffe0469290710, active_cred=0xfffff8000b07d800, file_cred=0x1, 
>>>     td=0xfffff801b5063000) at vnode_if.h:309
>>> #9  0xffffffff806017e4 in kern_statat (td=0xfffff801b5063000, 
>>>     flag=<value optimized out>, fd=<value optimized out>, 
>>>     path=<value optimized out>, pathseg=UIO_USERSPACE, 
>>>     sbp=0xfffffe04692908a0, hook=0xfefff80034ba0700)
>>>     at /usr/src/sys/kern/vfs_syscalls.c:2241
>>> #10 0xffffffff80601acc in sys_fstatat (td=0xfffff802dbc03dc8, 
>>>     uap=0xfffffe04692909c0) at /usr/src/sys/kern/vfs_syscalls.c:2215
>>> #11 0xffffffff807a8db9 in amd64_syscall (td=0xfffff801b5063000, traced=0)
>>>     at subr_syscall.c:133
>>> #12 0xffffffff8078db2b in Xfast_syscall ()
>>>     at /usr/src/sys/amd64/amd64/exception.S:395
>> I probably can't help debug this, but someone who _can_ will likely ask
>> for this from kgdb:
>>
>> f 6
>> x/i $rip
>> info reg
> (kgdb) f 6
> #6  0xffffffff80754567 in ufs_getattr (ap=<value optimized out>)
>     at /usr/src/sys/ufs/ufs/ufs_vnops.c:463
> 463                     vap->va_atime.tv_sec = ip->i_din2->di_atime;
> (kgdb) x/i $rip
> 0xffffffff80754567 <ufs_getattr+135>:   mov    0x20(%rax),%rax
> (kgdb) info reg
> rax            0xfefff80034ba0700       -72066389246343424

This looks very similar to the GPF panic you reported a week ago.  A
single bit has been flipped in the %rax register.  It should begin with
0xff, not 0xfe.  I would strongly suspect that you have some failing
hardware, most commonly memory.

> rbx            0xfffff802dbc03dc8       -8783816278584
> rcx            0x1      1
> rdx            0xfffff8000b07d800       -8795907958784
> rsi            0xfffffe0469290688       -2180079090040
> rdi            0xfffff802dbc03dc8       -8783816278584
> rbp            0xfffffe04692905a0       0xfffffe04692905a0
> rsp            0xfffffe0469290570       0xfffffe0469290570
> r8             0xfffff801b5063000       -8788760973312
> r9             0x33     51
> r10            0x0      0
> r11            0x0      0
> r12            0xfffff801b5063000       -8788760973312
> r13            0xfffffe04692905e0       -2180079090208
> r14            0xfffff80088086000       -8793810771968
> r15            0xfffff800880860b0       -8793810771792
> rip            0xffffffff80754567       0xffffffff80754567 <ufs_getattr+135>
> eflags         0x10202  66050
> cs             0x20     32
> ss             0x28     40
> ds             0x0      0
> es             0x0      0
> fs             0x0      0
> gs             0x0      0
>
Received on Mon Feb 02 2015 - 17:29:47 UTC

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