Re: Panic in sys_fstatat()
On Fri, Feb 15, 2019 at 09:50:55AM +0200, Andriy Gapon wrote: > > So, I suspect something exotic like some sort of a stack alignment issue, or a > CPU bug, or a mismatch between object files, or some local experiment, etc. > You might be right about something exotic. It is an old laptop, so it could be showing signs of hardware failure. I'm also unfortuntely trying to solve an issue with drm-legacy-kmod. In building several different kernels over a few different revisions of -current, I seem to have jump across the introduction of ifunc into the linkers. I'll see if I can come up with a repeatable method for causing the panic. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic in sys_fstatat()
On 14/02/2019 22:26, John Baldwin wrote: > On 2/13/19 6:47 PM, Steve Kargl wrote: ... >> panic: vm_fault_hold: fault on nofault entry, addr: 0x202000 What's very suspicious here is that the fault address looks a lot like LK_SHARED | LK_NODDLKTREAT, which would be 'flags' passed to vn_lock and which should never be used as an address. In a later email Steve reported that cn_lkflags = 2097152 and that's 0x20, LK_SHARED. compute_cn_lkflags() adds LK_NODDLKTREAT. However, LK_RETRY is missing. >> cpuid = 1 >> time = 1550111772 >> KDB: stack backtrace: >> db_trace_self_wrapper(10b42f3,8c96000,1,9341bd0,2e7b6590,...) at >> db_trace_self_wrapper+0x2a/frame 0x2e7b6560 >> kdb_backtrace(109973a,5c64d41c,0,2e7b661c,1,...) at kdb_backtrace+0x2d/frame >> 0x2e7b65c8 >> vpanic(108d309,2e7b661c,2e7b661c,2e7b6700,f734a9,...) at vpanic+0x141/frame >> 0x2e7b65fc >> panic(108d309,103dfa3,202000,2e7b6664,2e7b6654,...) at panic+0x1b/frame >> 0x2e7b6610 >> vm_fault_hold(1ea5000,202000,1,0,0,...) at vm_fault_hold+0x29e9/frame >> 0x2e7b6700 >> vm_fault(1ea5000,202000,1,0,0,...) at vm_fault+0x5e/frame 0x2e7b6728 >> trap_pfault(202462,40,109e2f2,316d3480,2e7b67c0,...) at >> trap_pfault+0xb2/frame 0x2e7b6770 >> trap(2e7b6880,8,28,28,1836a120,...) at trap+0x3cb/frame 0x2e7b6874 >> calltrap() at PTDpde+0x4165/frame 0x2e7b6874 >> --- trap 0xc, eip = 0x1027fb8, esp = 0x2e7b68c0, ebp = 0x2e7b68f8 --- >> VOP_LOCK1_APV(1836a120,202400,1099cc5,2c8,2e7b6ab0,...) at >> VOP_LOCK1_APV+0x8/frame 0x2e7b68f8 And [0x]202400 here confirms the above observations. [0x]2c8 is 712, the line number in vfs_lookup.c. >> lookup(2e7b6a50,0,400,2e7b6aa0,2e7b6a18,...) at lookup+0xc4/frame 0x2e7b6960 >> namei(2e7b6a50,0,4000144,0,2cced08e,...) at namei+0x4f3/frame 0x2e7b6a20 >> kern_statat(3c5dc700,0,ff9c,2cced08e,0,...) at kern_statat+0x85/frame >> 0x2e7b6af0 >> sys_fstatat(3c5dc700,3c5dc988,1384bb0,3c5dc700,0,...) at >> sys_fstatat+0x49/frame 0x2e7b6c00 >> syscall(2e7b6ce8,3b,3b,3b,fbafbbc8,...) at syscall+0x3ea/frame 0x2e7b6cdc >> Xint0x80_syscall() at PTDpde+0x43af/frame 0x2e7b6cdc > > Frame 18 is probably the root problem, though it doesn't look like kgdb is > able to unwind it correctly. Looking at frame 19 might help though. It > seems like a NULL pointer dereference when invoking VOP_LOCK. > So, I suspect something exotic like some sort of a stack alignment issue, or a CPU bug, or a mismatch between object files, or some local experiment, etc. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic in sys_fstatat()
On Thu, Feb 14, 2019 at 12:47:26PM -0800, John Baldwin wrote:
> On 2/14/19 12:38 PM, Steve Kargl wrote:
> > On Thu, Feb 14, 2019 at 12:26:01PM -0800, John Baldwin wrote:
> >> On 2/13/19 6:47 PM, Steve Kargl wrote:
> >>> #16 0x00ff58bb in trap (frame=0x2e7b6880) at
> >>> /usr/src/sys/i386/i386/trap.c:519
> >>> #17 0xffc0315d in ?? ()
> >>> #18 0x2e7b6880 in ?? ()
> >>> #19 0x00d1de64 in lookup (ndp=0x2e7b6a50)
> >>> at /usr/src/sys/kern/vfs_lookup.c:710
> >>> #20 0x00d1d763 in namei (ndp=0x2e7b6a50) at
> >>> /usr/src/sys/kern/vfs_lookup.c:487
> >>> #21 0x00d372c5 in kern_statat (td=0x3c5dc700, flag=0, fd=-100,
> >>> path=0x2cced08e ,
> >>> pathseg=UIO_USERSPACE, sbp=0x2e7b6b18, hook=0x0)
> >>> at /usr/src/sys/kern/vfs_syscalls.c:2307
> >>> #22 0x00d37c99 in sys_fstatat (td=0x3c5dc700, uap=0x3c5dc988)
> >>> at /usr/src/sys/kern/vfs_syscalls.c:2284
> >>> #23 0x00ff69fa in syscallenter (td=)
> >>> at /usr/src/sys/i386/i386/../../kern/subr_syscall.c:135
> >>> #24 syscall (frame=0x2e7b6ce8) at /usr/src/sys/i386/i386/trap.c:1144
> >>> #25 0xffc033a7 in ?? ()
> >>> #26 0x2e7b6ce8 in ?? ()
> >>> Backtrace stopped: Cannot access memory at address 0xfbafbbbc
> >>> (kgdb)
> >>
> >> Frame 18 is probably the root problem, though it doesn't look like kgdb is
> >> able to unwind it correctly. Looking at frame 19 might help though. It
> >> seems like a NULL pointer dereference when invoking VOP_LOCK.
> >>
> >
> > I can't look at this until tonight (about 6-7 hours).
> > Anything in frame 19 that you would be particularly
> > interested in?
>
> Just what source line it is and what the value of the arguments passed to the
> function it is calling are. Probably it's vn_lock() or VOP_LOCK() and it's
> most likely the 'vp' that is NULL, but it would be good to see all the args
> passed to the function if possible.
>
I can make kernel.debug and vmcore.0 available on freefall
if that would help someone look this over.
__curthread () at ./machine/pcpu.h:226
226 __asm("movl %%fs:%1,%0" : "=r" (td)
(kgdb) frame 19
#19 0x00d1de64 in lookup (ndp=0x2e7b6a50) at /usr/src/sys/kern/vfs_lookup.c:710
710 vn_lock(dp,
(kgdb) list
705 * we adjust based on the requesting flags.
706 */
707 cnp->cn_lkflags = LK_SHARED;
708 dp = ndp->ni_startdir;
709 ndp->ni_startdir = NULLVP;
710 vn_lock(dp,
711 compute_cn_lkflags(dp->v_mount, cnp->cn_lkflags | LK_RETRY,
712 cnp->cn_flags));
713
714 dirloop:
(kgdb) p *cnp
$1 = {cn_nameiop = 0, cn_flags = 67109188, cn_thread = 0x3c5dc700,
cn_cred = 0x2fd5b300, cn_lkflags = 2097152,
cn_pnbuf = 0x181dac00
"/usr/home/kargl/.mozilla/seamonkey/565lcgtb.default/cert9.db-journal",
cn_nameptr = 0x181dac01
"usr/home/kargl/.mozilla/seamonkey/565lcgtb.default/cert9.db-journal",
cn_namelen = 18180272}
(kgdb) p *cnp->cn_thread
$3 = {td_lock = 0x133e76c , td_proc = 0x2f6f9a08, td_plist = {
tqe_next = 0x3c5f2000, tqe_prev = 0x333ac708}, td_runq = {tqe_next = 0x0,
tqe_prev = 0x133ece0 }, td_slpq = {tqe_next = 0x0,
tqe_prev = 0x8dd34c0}, td_lockq = {tqe_next = 0x0, tqe_prev = 0x2e5d99d0},
td_hash = {le_next = 0x0, le_prev = 0x8b6f0d0}, td_cpuset = 0x8b74f80,
td_domain = {dr_policy = 0x132c1c0 , dr_iter = 0},
td_sel = 0x31e94500, td_sleepqueue = 0x8dd34c0, td_turnstile = 0x8dd7900,
td_rlqe = 0x183adefc, td_umtxq = 0x2eac6000, td_tid = 100404, td_sigqueue = {
sq_signals = {__bits = {0, 0, 0, 0}}, sq_kill = {__bits = {0, 0, 0, 0}},
sq_ptrace = {__bits = {0, 0, 0, 0}}, sq_list = {tqh_first = 0x0,
tqh_last = 0x3c5dc784}, sq_proc = 0x2f6f9a08, sq_flags = 1},
td_lend_user_pri = 255 '\377', td_epochnest = 0 '\000', td_flags = 16842756,
td_inhibitors = 0, td_pflags = 0, td_dupfd = 0, td_sqqueue = 0,
td_wchan = 0x0, td_wmesg = 0x0, td_owepreempt = 0 '\000',
td_tsqueue = 0 '\000', td_locks = 0, td_rw_rlocks = 0, td_sx_slocks = 0,
td_lk_slocks = 0, td_stopsched = 1, td_blocked = 0x0, td_lockname = 0x0,
td_contested = {lh_first = 0x0}, td_sleeplocks = 0x0,
td_intr_nesting_level = 0, td_pinned = 1, td_ucred = 0x2fd5b300,
td_limit = 0x2f4e0300, td_slptick = 0, td_blktick = 0,
td_swvoltick = -2027751151, td_swinvoltick = -2027751162, td_cow = 414,
td_ru = {ru_utime = {tv_sec = 0, tv_usec = 0}, ru_stime = {tv_sec = 0,
tv_usec = 0}, ru_maxrss = 766720, ru_ixrss = 2820160, ru_idrss = 80576,
ru_isrss = 12122624, ru_minflt = 6983, ru_majflt = 0, ru_nswap = 0,
ru_inblock = 0, ru_oublock = 0, ru_msgsnd = 4421, ru_msgrcv = 36987,
ru_nsignals = 0, ru_nvcsw = 18339, ru_nivcsw = 78866}, td_rux = {
rux_runtime = 313960691210, rux_uticks = 17521, rux_sticks = 2521,
rux_iticks = 0, rux_uu = 0, rux_su = 0, rux_tu = 0},
td_incruntime = 1647457400, td_runtime = 315608148610, td_pticks = 0,
td_sticks = 16, td_iticks = 0, td_uticks = 86, td_intrval = 0,
td_oldsigmask = {__bit
Re: Panic in sys_fstatat()
On 2/14/19 12:38 PM, Steve Kargl wrote: > On Thu, Feb 14, 2019 at 12:26:01PM -0800, John Baldwin wrote: >> On 2/13/19 6:47 PM, Steve Kargl wrote: >>> #16 0x00ff58bb in trap (frame=0x2e7b6880) at >>> /usr/src/sys/i386/i386/trap.c:519 >>> #17 0xffc0315d in ?? () >>> #18 0x2e7b6880 in ?? () >>> #19 0x00d1de64 in lookup (ndp=0x2e7b6a50) >>> at /usr/src/sys/kern/vfs_lookup.c:710 >>> #20 0x00d1d763 in namei (ndp=0x2e7b6a50) at >>> /usr/src/sys/kern/vfs_lookup.c:487 >>> #21 0x00d372c5 in kern_statat (td=0x3c5dc700, flag=0, fd=-100, >>> path=0x2cced08e , >>> pathseg=UIO_USERSPACE, sbp=0x2e7b6b18, hook=0x0) >>> at /usr/src/sys/kern/vfs_syscalls.c:2307 >>> #22 0x00d37c99 in sys_fstatat (td=0x3c5dc700, uap=0x3c5dc988) >>> at /usr/src/sys/kern/vfs_syscalls.c:2284 >>> #23 0x00ff69fa in syscallenter (td=) >>> at /usr/src/sys/i386/i386/../../kern/subr_syscall.c:135 >>> #24 syscall (frame=0x2e7b6ce8) at /usr/src/sys/i386/i386/trap.c:1144 >>> #25 0xffc033a7 in ?? () >>> #26 0x2e7b6ce8 in ?? () >>> Backtrace stopped: Cannot access memory at address 0xfbafbbbc >>> (kgdb) >> >> Frame 18 is probably the root problem, though it doesn't look like kgdb is >> able to unwind it correctly. Looking at frame 19 might help though. It >> seems like a NULL pointer dereference when invoking VOP_LOCK. >> > > I can't look at this until tonight (about 6-7 hours). > Anything in frame 19 that you would be particularly > interested in? Just what source line it is and what the value of the arguments passed to the function it is calling are. Probably it's vn_lock() or VOP_LOCK() and it's most likely the 'vp' that is NULL, but it would be good to see all the args passed to the function if possible. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic in sys_fstatat()
On Thu, Feb 14, 2019 at 12:26:01PM -0800, John Baldwin wrote: > On 2/13/19 6:47 PM, Steve Kargl wrote: > > #16 0x00ff58bb in trap (frame=0x2e7b6880) at > > /usr/src/sys/i386/i386/trap.c:519 > > #17 0xffc0315d in ?? () > > #18 0x2e7b6880 in ?? () > > #19 0x00d1de64 in lookup (ndp=0x2e7b6a50) > > at /usr/src/sys/kern/vfs_lookup.c:710 > > #20 0x00d1d763 in namei (ndp=0x2e7b6a50) at > > /usr/src/sys/kern/vfs_lookup.c:487 > > #21 0x00d372c5 in kern_statat (td=0x3c5dc700, flag=0, fd=-100, > > path=0x2cced08e , > > pathseg=UIO_USERSPACE, sbp=0x2e7b6b18, hook=0x0) > > at /usr/src/sys/kern/vfs_syscalls.c:2307 > > #22 0x00d37c99 in sys_fstatat (td=0x3c5dc700, uap=0x3c5dc988) > > at /usr/src/sys/kern/vfs_syscalls.c:2284 > > #23 0x00ff69fa in syscallenter (td=) > > at /usr/src/sys/i386/i386/../../kern/subr_syscall.c:135 > > #24 syscall (frame=0x2e7b6ce8) at /usr/src/sys/i386/i386/trap.c:1144 > > #25 0xffc033a7 in ?? () > > #26 0x2e7b6ce8 in ?? () > > Backtrace stopped: Cannot access memory at address 0xfbafbbbc > > (kgdb) > > Frame 18 is probably the root problem, though it doesn't look like kgdb is > able to unwind it correctly. Looking at frame 19 might help though. It > seems like a NULL pointer dereference when invoking VOP_LOCK. > I can't look at this until tonight (about 6-7 hours). Anything in frame 19 that you would be particularly interested in? -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic in sys_fstatat()
On 2/13/19 6:47 PM, Steve Kargl wrote:
> I have the core file and kernel.debug, if someone
> wnat additional information.
>
> mobile dumped core - see /var/crash/vmcore.0
>
> Wed Feb 13 18:37:44 PST 2019
>
> FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r344034M: Tue Feb 12
> 08:14:16 PST 2019 root@mobile:/usr/obj/usr/src/i386.i386/sys/MOBILE i386
>
> panic: vm_fault_hold: fault on nofault entry, addr: 0x202000
>
> GNU gdb (GDB) 8.2.1 [GDB v8.2.1 for FreeBSD]
> Reading symbols from /boot/kernel/kernel...Reading symbols from
> /usr/lib/debug//boot/kernel/kernel.debug...done.
> done.
>
> Unread portion of the kernel message buffer:
> panic: vm_fault_hold: fault on nofault entry, addr: 0x202000
> cpuid = 1
> time = 1550111772
> KDB: stack backtrace:
> db_trace_self_wrapper(10b42f3,8c96000,1,9341bd0,2e7b6590,...) at
> db_trace_self_wrapper+0x2a/frame 0x2e7b6560
> kdb_backtrace(109973a,5c64d41c,0,2e7b661c,1,...) at kdb_backtrace+0x2d/frame
> 0x2e7b65c8
> vpanic(108d309,2e7b661c,2e7b661c,2e7b6700,f734a9,...) at vpanic+0x141/frame
> 0x2e7b65fc
> panic(108d309,103dfa3,202000,2e7b6664,2e7b6654,...) at panic+0x1b/frame
> 0x2e7b6610
> vm_fault_hold(1ea5000,202000,1,0,0,...) at vm_fault_hold+0x29e9/frame
> 0x2e7b6700
> vm_fault(1ea5000,202000,1,0,0,...) at vm_fault+0x5e/frame 0x2e7b6728
> trap_pfault(202462,40,109e2f2,316d3480,2e7b67c0,...) at
> trap_pfault+0xb2/frame 0x2e7b6770
> trap(2e7b6880,8,28,28,1836a120,...) at trap+0x3cb/frame 0x2e7b6874
> calltrap() at PTDpde+0x4165/frame 0x2e7b6874
> --- trap 0xc, eip = 0x1027fb8, esp = 0x2e7b68c0, ebp = 0x2e7b68f8 ---
> VOP_LOCK1_APV(1836a120,202400,1099cc5,2c8,2e7b6ab0,...) at
> VOP_LOCK1_APV+0x8/frame 0x2e7b68f8
> lookup(2e7b6a50,0,400,2e7b6aa0,2e7b6a18,...) at lookup+0xc4/frame 0x2e7b6960
> namei(2e7b6a50,0,4000144,0,2cced08e,...) at namei+0x4f3/frame 0x2e7b6a20
> kern_statat(3c5dc700,0,ff9c,2cced08e,0,...) at kern_statat+0x85/frame
> 0x2e7b6af0
> sys_fstatat(3c5dc700,3c5dc988,1384bb0,3c5dc700,0,...) at
> sys_fstatat+0x49/frame 0x2e7b6c00
> syscall(2e7b6ce8,3b,3b,3b,fbafbbc8,...) at syscall+0x3ea/frame 0x2e7b6cdc
> Xint0x80_syscall() at PTDpde+0x43af/frame 0x2e7b6cdc
> --- syscall (552, FreeBSD ELF32, sys_fstatat), eip = 0x21321d5f, esp =
> 0xfbafbb2c, ebp = 0xfbafbbb8 ---
> _DYNAMIC() at 0x21321d5f
> KDB: enter: panic
>
> __curthread () at ./machine/pcpu.h:226
> 226 __asm("movl %%fs:%1,%0" : "=r" (td)
> (kgdb) #0 __curthread () at ./machine/pcpu.h:226
> #1 doadump (textdump=)
> at /usr/src/sys/kern/kern_shutdown.c:371
> #2 0x009c023d in db_fncall_generic (addr=,
> rv=, nargs=, args=)
> at /usr/src/sys/ddb/db_command.c:609
> #3 db_fncall (dummy1=20441604, dummy2=false, dummy3=10607414,
> dummy4=0x2e7b6344 "") at /usr/src/sys/ddb/db_command.c:657
> #4 0x009bfd74 in db_command (last_cmdp=,
> cmd_table=, dopager=1) at /usr/src/sys/ddb/db_command.c:481
> #5 0x009bfae0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:534
> #6 0x009c2d6b in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:252
> #7 0x00ca66d4 in kdb_trap (type=3, code=0, tf=0x2e7b657c)
> at /usr/src/sys/kern/subr_kdb.c:692
> #8 0x00ff58a4 in trap (frame=0x2e7b657c) at /usr/src/sys/i386/i386/trap.c:712
> #9 0xffc0315d in ?? ()
> #10 0x2e7b657c in ?? ()
> #11 0x00c5bede in vpanic (
> fmt=0x108d309 "%s: fault on nofault entry, addr: %#lx",
> ap=0x2e7b661c "\243\337\003\001") at /usr/src/sys/kern/kern_shutdown.c:866
> #12 0x00c5bd7b in panic (
> fmt=0x108d309 "%s: fault on nofault entry, addr: %#lx")
> at /usr/src/sys/kern/kern_shutdown.c:804
> #13 0x00f734a9 in vm_fault_hold (map=0x1ea5000, vaddr=2105344,
> fault_type=1 '\001', fault_flags=0, m_hold=0x0)
> at /usr/src/sys/vm/vm_fault.c:586
> #14 0x00f70a6e in vm_fault (map=0x1ea5000, vaddr=2105344,
> fault_type=1 '\001', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:536
> #15 0x00ff62b2 in trap_pfault (frame=0x2e7b6880, usermode=0, eva=2106466)
> at /usr/src/sys/i386/i386/trap.c:882
> #16 0x00ff58bb in trap (frame=0x2e7b6880) at /usr/src/sys/i386/i386/trap.c:519
> #17 0xffc0315d in ?? ()
> #18 0x2e7b6880 in ?? ()
> #19 0x00d1de64 in lookup (ndp=0x2e7b6a50)
> at /usr/src/sys/kern/vfs_lookup.c:710
> #20 0x00d1d763 in namei (ndp=0x2e7b6a50) at /usr/src/sys/kern/vfs_lookup.c:487
> #21 0x00d372c5 in kern_statat (td=0x3c5dc700, flag=0, fd=-100,
> path=0x2cced08e ,
> pathseg=UIO_USERSPACE, sbp=0x2e7b6b18, hook=0x0)
> at /usr/src/sys/kern/vfs_syscalls.c:2307
> #22 0x00d37c99 in sys_fstatat (td=0x3c5dc700, uap=0x3c5dc988)
> at /usr/src/sys/kern/vfs_syscalls.c:2284
> #23 0x00ff69fa in syscallenter (td=)
> at /usr/src/sys/i386/i386/../../kern/subr_syscall.c:135
> #24 syscall (frame=0x2e7b6ce8) at /usr/src/sys/i386/i386/trap.c:1144
> #25 0xffc033a7 in ?? ()
> #26 0x2e7b6ce8 in ?? ()
> Backtrace stopped: Cannot access memory at address 0xfbafbbbc
> (kgdb)
Frame 18 is probably the root problem, though it doesn't look like k
Re: panic in sys_fstatat (?)
On Mon, Feb 02, 2015 at 12:32:02PM -0800, Chris H wrote: > On Mon, 2 Feb 2015 10:39:43 -0800 Steve Kargl > > > > Yep, same hardware. And, yes, I'm beginning to think it > > is hardware as no one else is reporting a problem. > > > > The system is less than 2 month old. :( > FWIW given the system is so young, you might want to > consider BUS/CPU timing, or PSU (power supply) before > giving up on the board/CPU/RAM. > I had [apparent] CPU cache failures that ultimately turned > out to be the PSU. So thought it worth mentioning. :) > memtest86+ indicates that it is indeed a memory module. Sorry about the seemingly bogus kernel panic emails. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic in sys_fstatat (?)
On Mon, 2 Feb 2015 10:39:43 -0800 Steve Kargl wrote > On Mon, Feb 02, 2015 at 08:29:52PM +0200, Konstantin Belousov wrote: > > On Mon, Feb 02, 2015 at 10:22:36AM -0800, Steve Kargl wrote: > > > (kgdb) f 6 > > > #6 0x80754567 in ufs_getattr (ap=) > > > 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 > > > 0x80754567 : mov0x20(%rax),%rax > > > (kgdb) info reg > > > rax0xfefff80034ba0700 -72066389246343424 > > Note the single-bit error in the 0xf_e_fff8... address above. > > Is this the same machine you reported the panic in pmap ? > > > > May be, run memtest ? > > > > Yep, same hardware. And, yes, I'm beginning to think it > is hardware as no one else is reporting a problem. > > The system is less than 2 month old. :( FWIW given the system is so young, you might want to consider BUS/CPU timing, or PSU (power supply) before giving up on the board/CPU/RAM. I had [apparent] CPU cache failures that ultimately turned out to be the PSU. So thought it worth mentioning. :) --Chris > > -- > Steve > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic in sys_fstatat (?)
On Mon, Feb 02, 2015 at 08:29:52PM +0200, Konstantin Belousov wrote: > On Mon, Feb 02, 2015 at 10:22:36AM -0800, Steve Kargl wrote: > > (kgdb) f 6 > > #6 0x80754567 in ufs_getattr (ap=) > > 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 > > 0x80754567 : mov0x20(%rax),%rax > > (kgdb) info reg > > rax0xfefff80034ba0700 -72066389246343424 > Note the single-bit error in the 0xf_e_fff8... address above. > Is this the same machine you reported the panic in pmap ? > > May be, run memtest ? > Yep, same hardware. And, yes, I'm beginning to think it is hardware as no one else is reporting a problem. The system is less than 2 month old. :( -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic in sys_fstatat (?)
On Mon, Feb 02, 2015 at 10:22:36AM -0800, 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 0x80559f47 in kern_reboot (howto=260) > > > at /usr/src/sys/kern/kern_shutdown.c:448 > > > #2 0x8055a3b0 in panic (fmt=) > > > at /usr/src/sys/kern/kern_shutdown.c:747 > > > #3 0x807a85c0 in trap_fatal (frame=, > > > eva=) at /usr/src/sys/amd64/amd64/trap.c:861 > > > #4 0x807a8221 in trap (frame=) > > > at /usr/src/sys/amd64/amd64/trap.c:201 > > > #5 0x8078d843 in calltrap () > > > at /usr/src/sys/amd64/amd64/exception.S:235 > > > #6 0x80754567 in ufs_getattr (ap=) > > > at /usr/src/sys/ufs/ufs/ufs_vnops.c:463 > > > #7 0x808074fa in VOP_GETATTR_APV (vop=, > > > a=) at vnode_if.c:731 > > > #8 0x80607e62 in vn_stat (vp=0xf80088086000, > > > sb=0xfe0469290710, active_cred=0xf8000b07d800, file_cred=0x1, > > > td=0xf801b5063000) at vnode_if.h:309 > > > #9 0x806017e4 in kern_statat (td=0xf801b5063000, > > > flag=, fd=, > > > path=, pathseg=UIO_USERSPACE, > > > sbp=0xfe04692908a0, hook=0xfefff80034ba0700) > > > at /usr/src/sys/kern/vfs_syscalls.c:2241 > > > #10 0x80601acc in sys_fstatat (td=0xf802dbc03dc8, > > > uap=0xfe04692909c0) at /usr/src/sys/kern/vfs_syscalls.c:2215 > > > #11 0x807a8db9 in amd64_syscall (td=0xf801b5063000, traced=0) > > > at subr_syscall.c:133 > > > #12 0x8078db2b 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 0x80754567 in ufs_getattr (ap=) > 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 > 0x80754567 : mov0x20(%rax),%rax > (kgdb) info reg > rax0xfefff80034ba0700 -72066389246343424 Note the single-bit error in the 0xf_e_fff8... address above. Is this the same machine you reported the panic in pmap ? May be, run memtest ? > rbx0xf802dbc03dc8 -8783816278584 > rcx0x1 1 > rdx0xf8000b07d800 -8795907958784 > rsi0xfe0469290688 -2180079090040 > rdi0xf802dbc03dc8 -8783816278584 > rbp0xfe04692905a0 0xfe04692905a0 > rsp0xfe0469290570 0xfe0469290570 > r8 0xf801b5063000 -8788760973312 > r9 0x33 51 > r100x0 0 > r110x0 0 > r120xf801b5063000 -8788760973312 > r130xfe04692905e0 -2180079090208 > r140xf80088086000 -8793810771968 > r150xf800880860b0 -8793810771792 > rip0x80754567 0x80754567 > eflags 0x10202 66050 > cs 0x20 32 > ss 0x28 40 > ds 0x0 0 > es 0x0 0 > fs 0x0 0 > gs 0x0 0 > > -- > Steve > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic in sys_fstatat (?)
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 0x80559f47 in kern_reboot (howto=260) >>> at /usr/src/sys/kern/kern_shutdown.c:448 >>> #2 0x8055a3b0 in panic (fmt=) >>> at /usr/src/sys/kern/kern_shutdown.c:747 >>> #3 0x807a85c0 in trap_fatal (frame=, >>> eva=) at /usr/src/sys/amd64/amd64/trap.c:861 >>> #4 0x807a8221 in trap (frame=) >>> at /usr/src/sys/amd64/amd64/trap.c:201 >>> #5 0x8078d843 in calltrap () >>> at /usr/src/sys/amd64/amd64/exception.S:235 >>> #6 0x80754567 in ufs_getattr (ap=) >>> at /usr/src/sys/ufs/ufs/ufs_vnops.c:463 >>> #7 0x808074fa in VOP_GETATTR_APV (vop=, >>> a=) at vnode_if.c:731 >>> #8 0x80607e62 in vn_stat (vp=0xf80088086000, >>> sb=0xfe0469290710, active_cred=0xf8000b07d800, file_cred=0x1, >>> td=0xf801b5063000) at vnode_if.h:309 >>> #9 0x806017e4 in kern_statat (td=0xf801b5063000, >>> flag=, fd=, >>> path=, pathseg=UIO_USERSPACE, >>> sbp=0xfe04692908a0, hook=0xfefff80034ba0700) >>> at /usr/src/sys/kern/vfs_syscalls.c:2241 >>> #10 0x80601acc in sys_fstatat (td=0xf802dbc03dc8, >>> uap=0xfe04692909c0) at /usr/src/sys/kern/vfs_syscalls.c:2215 >>> #11 0x807a8db9 in amd64_syscall (td=0xf801b5063000, traced=0) >>> at subr_syscall.c:133 >>> #12 0x8078db2b 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 0x80754567 in ufs_getattr (ap=) > 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 > 0x80754567 : mov0x20(%rax),%rax > (kgdb) info reg > rax0xfefff80034ba0700 -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. > rbx0xf802dbc03dc8 -8783816278584 > rcx0x1 1 > rdx0xf8000b07d800 -8795907958784 > rsi0xfe0469290688 -2180079090040 > rdi0xf802dbc03dc8 -8783816278584 > rbp0xfe04692905a0 0xfe04692905a0 > rsp0xfe0469290570 0xfe0469290570 > r8 0xf801b5063000 -8788760973312 > r9 0x33 51 > r100x0 0 > r110x0 0 > r120xf801b5063000 -8788760973312 > r130xfe04692905e0 -2180079090208 > r140xf80088086000 -8793810771968 > r150xf800880860b0 -8793810771792 > rip0x80754567 0x80754567 > eflags 0x10202 66050 > cs 0x20 32 > ss 0x28 40 > ds 0x0 0 > es 0x0 0 > fs 0x0 0 > gs 0x0 0 > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic in sys_fstatat (?)
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 0x80559f47 in kern_reboot (howto=260) > > at /usr/src/sys/kern/kern_shutdown.c:448 > > #2 0x8055a3b0 in panic (fmt=) > > at /usr/src/sys/kern/kern_shutdown.c:747 > > #3 0x807a85c0 in trap_fatal (frame=, > > eva=) at /usr/src/sys/amd64/amd64/trap.c:861 > > #4 0x807a8221 in trap (frame=) > > at /usr/src/sys/amd64/amd64/trap.c:201 > > #5 0x8078d843 in calltrap () > > at /usr/src/sys/amd64/amd64/exception.S:235 > > #6 0x80754567 in ufs_getattr (ap=) > > at /usr/src/sys/ufs/ufs/ufs_vnops.c:463 > > #7 0x808074fa in VOP_GETATTR_APV (vop=, > > a=) at vnode_if.c:731 > > #8 0x80607e62 in vn_stat (vp=0xf80088086000, > > sb=0xfe0469290710, active_cred=0xf8000b07d800, file_cred=0x1, > > td=0xf801b5063000) at vnode_if.h:309 > > #9 0x806017e4 in kern_statat (td=0xf801b5063000, > > flag=, fd=, > > path=, pathseg=UIO_USERSPACE, > > sbp=0xfe04692908a0, hook=0xfefff80034ba0700) > > at /usr/src/sys/kern/vfs_syscalls.c:2241 > > #10 0x80601acc in sys_fstatat (td=0xf802dbc03dc8, > > uap=0xfe04692909c0) at /usr/src/sys/kern/vfs_syscalls.c:2215 > > #11 0x807a8db9 in amd64_syscall (td=0xf801b5063000, traced=0) > > at subr_syscall.c:133 > > #12 0x8078db2b 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 0x80754567 in ufs_getattr (ap=) 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 0x80754567 : mov0x20(%rax),%rax (kgdb) info reg rax0xfefff80034ba0700 -72066389246343424 rbx0xf802dbc03dc8 -8783816278584 rcx0x1 1 rdx0xf8000b07d800 -8795907958784 rsi0xfe0469290688 -2180079090040 rdi0xf802dbc03dc8 -8783816278584 rbp0xfe04692905a0 0xfe04692905a0 rsp0xfe0469290570 0xfe0469290570 r8 0xf801b5063000 -8788760973312 r9 0x33 51 r100x0 0 r110x0 0 r120xf801b5063000 -8788760973312 r130xfe04692905e0 -2180079090208 r140xf80088086000 -8793810771968 r150xf800880860b0 -8793810771792 rip0x80754567 0x80754567 eflags 0x10202 66050 cs 0x20 32 ss 0x28 40 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic in sys_fstatat (?)
On 02/02/2015 12:59, Steve Kargl wrote: > FreeBSD troutmask.apl.washington.edu 11.0-CURRENT FreeBSD 11.0-CURRENT > #0 r278102M: Mon Feb 2 09:15:48 PST 2015 > ka...@troutmask.apl.washington.edu:/data/obj/usr/src/sys/SPEW amd64 > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 2; apic id = 12 > instruction pointer = 0x20:0x80754567 > stack pointer = 0x28:0xfe0469290560 > frame pointer = 0x28:0xfe04692905a0 > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 62150 (rm) > trap number = 9 > panic: general protection fault > cpuid = 2 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0469290220 > panic() at panic+0x1c1/frame 0xfe04692902e0 > trap_fatal() at trap_fatal+0x380/frame 0xfe0469290340 > trap() at trap+0x6d1/frame 0xfe04692904a0 > calltrap() at calltrap+0x8/frame 0xfe04692904a0 > --- trap 0x9, rip = 0x80754567, rsp = 0xfe0469290560, rbp = > 0xfe04692905a0 --- > ufs_getattr() at ufs_getattr+0x87/frame 0xfe04692905a0 > VOP_GETATTR_APV() at VOP_GETATTR_APV+0x7a/frame 0xfe04692905d0 > vn_stat() at vn_stat+0x62/frame 0xfe04692906c0 > kern_statat() at kern_statat+0xe4/frame 0xfe0469290880 > sys_fstatat() at sys_fstatat+0x2c/frame 0xfe0469290920 > amd64_syscall() at amd64_syscall+0x289/frame 0xfe0469290a30 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0469290a30 > --- syscall (493, FreeBSD ELF64, sys_fstatat), rip = 0x2008b3e9a, rsp = > 0x7fffdc88, rbp = 0x7fffdd30 --- > Uptime: 10m14s > > > (kgdb) #0 doadump (textdump=Unhandled dwarf expression opcode 0x93 > ) at pcpu.h:219 > #1 0x80559f47 in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:448 > #2 0x8055a3b0 in panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:747 > #3 0x807a85c0 in trap_fatal (frame=, > eva=) at /usr/src/sys/amd64/amd64/trap.c:861 > #4 0x807a8221 in trap (frame=) > at /usr/src/sys/amd64/amd64/trap.c:201 > #5 0x8078d843 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:235 > #6 0x80754567 in ufs_getattr (ap=) > at /usr/src/sys/ufs/ufs/ufs_vnops.c:463 > #7 0x808074fa in VOP_GETATTR_APV (vop=, > a=) at vnode_if.c:731 > #8 0x80607e62 in vn_stat (vp=0xf80088086000, > sb=0xfe0469290710, active_cred=0xf8000b07d800, file_cred=0x1, > td=0xf801b5063000) at vnode_if.h:309 > #9 0x806017e4 in kern_statat (td=0xf801b5063000, > flag=, fd=, > path=, pathseg=UIO_USERSPACE, > sbp=0xfe04692908a0, hook=0xfefff80034ba0700) > at /usr/src/sys/kern/vfs_syscalls.c:2241 > #10 0x80601acc in sys_fstatat (td=0xf802dbc03dc8, > uap=0xfe04692909c0) at /usr/src/sys/kern/vfs_syscalls.c:2215 > #11 0x807a8db9 in amd64_syscall (td=0xf801b5063000, traced=0) > at subr_syscall.c:133 > #12 0x8078db2b 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 Eric ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
