----- Start Forwarded Message ----- Sent: Fri, 17 Mar 2017 12:47:30 -0700 From: John Baldwin <jhb_at_freebsd.org> To: jbtakk_at_iherebuywisely.com Subject: Re: info.0 dump good On Thursday, March 16, 2017 05:32:13 AM Jeffrey Bouquet wrote: > > On Wed, 15 Mar 2017 16:10:43 -0700, John Baldwin <jhb_at_freebsd.org> wrote: > > > On Monday, March 13, 2017 06:49:05 PM Jeffrey Bouquet wrote: > > > > > > On Mon, 13 Mar 2017 14:04:23 -0700, John Baldwin <jhb_at_freebsd.org> wrote: > > > > > > > On Monday, March 13, 2017 12:28:44 PM Jeffrey Bouquet wrote: > > > > > Seems to happen when Xorg has a large webpage or a page idle for a time > > > > > > > > > > Dump header from device: /dev/gpt/WDswap > > > > > Architecture: i386 > > > > > Architecture Version: 2 > > > > > Dump Length: 285376512 > > > > > Blocksize: 512 > > > > > Dumptime: Mon Mar 13 12:12:37 2017 > > > > > Hostname: [redacted]com > > > > > Magic: FreeBSD Kernel Dump > > > > > Version String: FreeBSD 12.0-CURRENT #5 r313487: Thu Feb 9 17:32:03 PST 2017 > > > > > com:/usr/obj/usr/src/sys/[custom kernel] > > > > > Panic String: page fault > > > > > Dump Parity: 1127850006 > > > > > Bounds: 0 > > > > > Dump Status: good > > > > > > > > > > Viable to send the bounds, info.0 and vmcore.0 to somewhere where someone not > > > > > a comlete novice can find a bug somewhere? Unsure what email attachment allows > > > > > a 273MB file, an ftp server upstream ?? No time to use kdbg for a few months anyway... > > > > > > > > Do you have a core.txt.0 file? If so it should contain a stack trace from > > > > kgdb which is the first thing that would be useful to obtain. > > > > > > > > > > Dump header from device: /dev/gpt/WDswap > > > Architecture: i386 > > > Architecture Version: 2 > > > Dump Length: 229535744 > > > Blocksize: 512 > > > Dumptime: Wed Mar 1 18:10:06 2017 > > > Hostname: .com > > > Magic: FreeBSD Kernel Dump > > > Version String: FreeBSD 12.0-CURRENT #0 r313487: Mon Feb 13 16:58:53 PST 2017 > > > root_at_ .com:/usr/obj/usr/src/sys/[custom] > > > Panic String: vm_fault: fault on nofault entry, addr: deadc000 > > > Dump Parity: 3513472583 > > > Bounds: 8 > > > Dump Status: good > > > > > > Only one of the core's has a .txt. file... this is .8 but lacks the 4th " bounds " file... > > > I just renamed them to capitallized [ the .8 that is ] for safekeeping. > > > > So the .txt files generally have much more useful information (such as the stack > > trace from kgdb). If you have a .txt file and it contains a stack trace, can > > you follow up on the list with the stack trace? > > > > > Don't know about the .text. file, Some versions of FreeBSD will generate a /var/crash/core.txt.N file alongside the /var/crash/vmcore.N and /var/crash/info.N files. If you have one, it will contain things like the backtrace from kgdb which are more useful than the info.N file. > Command: kgdb /boot/test/kernel VMCORE.8 > > some version of the output [below] from the above [core.text.8 also ? ] > > > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd"... > > Unread portion of the kernel message buffer: > Waiting (max 60 seconds) for system process `vnlru' to stop... done > Waiting (max 60 seconds) for system process `bufdaemon' to stop... done > Waiting (max 60 seconds) for system process `syncer' to stop... > Syncing disks, vnodes remaining... 5 1 0 0 done > All buffers synced. > lock order reversal: > 1st 0xbf8ce26c ufs (ufs) _at_ /usr/src/sys/kern/vfs_mount.c:1277 > 2nd 0xbfb90150 syncer (syncer) _at_ /usr/src/sys/kern/vfs_subr.c:2762 > stack backtrace: > #0 0xb5c22421 at witness_debugger+0x81 > #1 0xb5c22342 at witness_checkorder+0xd12 > #2 0xb5b9b5d4 at __lockmgr_args+0xa64 > #3 0xb5c784ad at vop_stdlock+0x4d > #4 0xb618e7f7 at VOP_LOCK1_APV+0xd7 > #5 0xb5c9c137 at _vn_lock+0xb7 > #6 0xb5c8b00a at vputx+0x16a > #7 0xb5c8286c at dounmount+0x5dc > #8 0xb5c8c8e8 at vfs_unmountall+0x68 > #9 0xb5c68333 at bufshutdown+0x3f3 > #10 0xb5bbfca7 at kern_reboot+0x1b7 > #11 0xb5bbfa88 at sys_reboot+0x3e8 > #12 0xb6155fa5 at syscall+0x3b5 > #13 0xb6140ede at Xint0x80_syscall+0x2e > lock order reversal: > 1st 0xbf8ce26c ufs (ufs) _at_ /usr/src/sys/kern/vfs_mount.c:1277 > 2nd 0xbfa28034 devfs (devfs) _at_ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1404 > stack backtrace: > #0 0xb5c22421 at witness_debugger+0x81 > #1 0xb5c22342 at witness_checkorder+0xd12 > #2 0xb5b9b5d4 at __lockmgr_args+0xa64 > #3 0xb5c784ad at vop_stdlock+0x4d > #4 0xb618e7f7 at VOP_LOCK1_APV+0xd7 > #5 0xb5c9c137 at _vn_lock+0xb7 > #6 0xb5eb9617 at ffs_flushfiles+0x157 > #7 0xb5e9d9aa at softdep_flushfiles+0x17a > #8 0xb5ebc04c at ffs_unmount+0x7c > #9 0xb5c8299b at dounmount+0x70b > #10 0xb5c8c8e8 at vfs_unmountall+0x68 > #11 0xb5c68333 at bufshutdown+0x3f3 > #12 0xb5bbfca7 at kern_reboot+0x1b7 > #13 0xb5bbfa88 at sys_reboot+0x3e8 > #14 0xb6155fa5 at syscall+0x3b5 > #15 0xb6140ede at Xint0x80_syscall+0x2e > lock order reversal: > 1st 0xbf69ab4c ufs (ufs) _at_ /usr/src/sys/kern/vfs_mount.c:1277 > 2nd 0xb6b6f8b0 allproc (allproc) _at_ /usr/src/sys/kern/kern_descrip.c:3104 > stack backtrace: > #0 0xb5c22421 at witness_debugger+0x81 > #1 0xb5c22342 at witness_checkorder+0xd12 > #2 0xb5bc976a at _sx_slock+0x5a > #3 0xb5b743f1 at mountcheckdirs+0x41 > #4 0xb5c828ea at dounmount+0x65a > #5 0xb5c8c93b at vfs_unmountall+0xbb > #6 0xb5c68333 at bufshutdown+0x3f3 > #7 0xb5bbfca7 at kern_reboot+0x1b7 > #8 0xb5bbfa88 at sys_reboot+0x3e8 > #9 0xb6155fa5 at syscall+0x3b5 > #10 0xb6140ede at Xint0x80_syscall+0x2e These messages are not as interesting. > Uptime: 3h49m18s > GEOM_SCHED: Modevent 2. > uhub11: detached > uhub9: detached > uhub10: detached > ums0: detached > <5>ue0: link state changed to DOWN > <5>Accounting disabled > panic: vm_fault: fault on nofault entry, addr: deadc000 > cpuid = 2 > KDB: stack backtrace: > db_trace_self_wrapper(b632dee0,b65ec9b0,0,b63057cc,20c,...) at db_trace_self_wrapper+0x2a/frame 0xeaa10428 > kdb_backtrace(b653d063,2,b6378ae5,eaa104e4,fb,...) at kdb_backtrace+0x2d/frame 0xeaa10490 > vpanic(b6378ae5,eaa104e4,eaa104e4,eaa105c0,b5edffb1,...) at vpanic+0x115/frame 0xeaa104c4 > panic(b6378ae5,deadc000,1,eaa1052c,eaa1051c,...) at panic+0x1b/frame 0xeaa104d8 > vm_fault_hold(b8172000,deadc000,1,0,0,...) at vm_fault_hold+0x2051/frame 0xeaa105c0 > vm_fault(b8172000,deadc000,1,0,c2d0bfa8,...) at vm_fault+0x88/frame 0xeaa105e8 > trap_pfault(deadc348,b6ae70ec,b6600504,bdda8d00,b6ae70f0,...) at trap_pfault+0x116/frame 0xeaa10630 > trap(eaa10778) at trap+0x2d6/frame 0xeaa1076c > calltrap() at calltrap+0x6/frame 0xeaa1076c > --- trap 0xc, eip = 0xb5bbaf19, esp = 0xeaa107b8, ebp = 0xeaa10828 --- > __rw_wlock_hard(c2d42ab4,deadc0de,be269000,b63585e2,139,...) at __rw_wlock_hard+0xe9/frame 0xeaa10828 > _rw_wlock_cookie(c2d42ab4,b63585e2,139,136,0,...) at _rw_wlock_cookie+0xd8/frame 0xeaa10858 > ip_output(c3acf400,0,0,0,0,...) at ip_output+0x4aa/frame 0xeaa10934 > check_dyn_rules(1,1,b632a786,eaa109c8,b5bce8a2,...) at check_dyn_rules+0x6a8/frame 0xeaa10994 > ipfw_dyn_tick(0,0,b632a786,2b1,eaa10a00,...) at ipfw_dyn_tick+0x55/frame 0xeaa109c8 > softclock_call_cc(0,0,b632a786,360,0,...) at softclock_call_cc+0x17c/frame 0xeaa10a68 > softclock(b6b6fa80,9,0,560,be2d4048,...) at softclock+0x40/frame 0xeaa10a88 > intr_event_execute_handlers(b6aa7e10,be2d4000,b6320f1d,560,b6320b58,...) at intr_event_execute_handlers+0x8e/frame 0xeaa10ab0 > ithread_loop(be2d7000,eaa10b28,b6320b58,406,0,...) at ithread_loop+0x90/frame 0xeaa10aec > fork_exit(b5b8a3c0,be2d7000,eaa10b28) at fork_exit+0x7e/frame 0xeaa10b14 > fork_trampoline() at fork_trampoline+0x8/frame 0xeaa10b14 > --- trap 0, eip = 0, esp = 0xeaa10b60, ebp = 0 --- > KDB: enter: panic This is the source of the panic, and it appears to be that the lock in question has been destroyed during shutdown but network packets are still being received. Please reply to the list with this kgdb output, and perhaps add 'bz_at_FreeBSD.org' to the list as he might know about when the associated lock is destroyed. > Reading symbols from /boot/test/geom_journal.ko...Reading symbols from /usr/lib/debug//boot/test/geom_journal.ko.debug...done. > done. > Loaded symbols for /boot/test/geom_journal.ko > Reading symbols from /boot/test/geom_label.ko...Reading symbols from /usr/lib/debug//boot/test/geom_label.ko.debug...done. > done. > Loaded symbols for /boot/test/geom_label.ko > Reading symbols from /boot/modules/nvidia-modeset.ko...done. > Loaded symbols for /boot/modules/nvidia-modeset.ko > Reading symbols from /boot/modules/nvidia.ko...done. > Loaded symbols for /boot/modules/nvidia.ko > Reading symbols from /boot/test/ehci.ko...Reading symbols from /usr/lib/debug//boot/test/ehci.ko.debug...done. > done. > Loaded symbols for /boot/test/ehci.ko > Reading symbols from /boot/test/geom_sched.ko...Reading symbols from /usr/lib/debug//boot/test/geom_sched.ko.debug...done. > done. > Loaded symbols for /boot/test/geom_sched.ko > Reading symbols from /boot/test/gsched_rr.ko...Reading symbols from /usr/lib/debug//boot/test/gsched_rr.ko.debug...done. > done. > Loaded symbols for /boot/test/gsched_rr.ko > Reading symbols from /boot/test/pf.ko...Reading symbols from /usr/lib/debug//boot/test/pf.ko.debug...done. > done. > Loaded symbols for /boot/test/pf.ko > Reading symbols from /boot/test/snd_csa.ko...Reading symbols from /usr/lib/debug//boot/test/snd_csa.ko.debug...done. > done. > Loaded symbols for /boot/test/snd_csa.ko > #0 doadump (textdump=0) at pcpu.h:225 > 225 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump (textdump=0) at pcpu.h:225 > #1 0xb555a40e in db_dump (dummy=-1245695404, dummy2=Unhandled dwarf expression opcode 0x9d > ) > at /usr/src/sys/ddb/db_command.c:546 > #2 0xb555a1fa in db_command (cmd_table=<value optimized out>) > at /usr/src/sys/ddb/db_command.c:453 > #3 0xb5559f50 in db_command_loop () at /usr/src/sys/ddb/db_command.c:506 > #4 0xb555cdfa in db_trap (type=<value optimized out>, > code=<value optimized out>) at /usr/src/sys/ddb/db_main.c:248 > #5 0xb5c03997 in kdb_trap (tf=<value optimized out>) > at /usr/src/sys/kern/subr_kdb.c:654 > #6 0xb615530f in trap (frame=<value optimized out>) > at /usr/src/sys/i386/i386/trap.c:683 > #7 0xb6140e2a in calltrap () at /usr/src/sys/i386/i386/exception.s:171 > #8 0xb5c03254 in kdb_enter (why=0xb6328738 "panic", msg=<value optimized out>) > at /usr/src/sys/kern/subr_kdb.c:444 > #9 0xb5bc03f2 in vpanic (fmt=<value optimized out>, ap=<value optimized out>) > at /usr/src/sys/kern/kern_shutdown.c:772 > #10 0xb5bc042b in panic ( > fmt=0xb6378ae5 "vm_fault: fault on nofault entry, addr: %lx") > at /usr/src/sys/kern/kern_shutdown.c:710 > #11 0xb5edffb1 in vm_fault_hold (vaddr=<value optimized out>, > fault_type=<value optimized out>, fault_flags=<value optimized out>) > at /usr/src/sys/vm/vm_fault.c:531 > ---Type <return> to continue, or q <return> to quit--- > #12 0xb5eddf28 in vm_fault (map=0xb8172000, vaddr=<value optimized out>, > fault_type=<value optimized out>, fault_flags=<value optimized out>) > at /usr/src/sys/vm/vm_fault.c:474 > #13 0xb61558c6 in trap_pfault (frame=0xeaa10778, > usermode=<value optimized out>, eva=<value optimized out>) > at /usr/src/sys/i386/i386/trap.c:868 > #14 0xb6154d06 in trap (frame=<value optimized out>) > at /usr/src/sys/i386/i386/trap.c:512 > #15 0xb6140e2a in calltrap () at /usr/src/sys/i386/i386/exception.s:171 > #16 0xb5bbaf19 in __rw_wlock_hard (c=<value optimized out>, > v=<value optimized out>, file=0x0, line=0) > at /usr/src/sys/kern/kern_rwlock.c:891 > #17 0xb5bbada8 in _rw_wlock_cookie (c=<value optimized out>, > file=<value optimized out>, line=<value optimized out>) > at /usr/src/sys/kern/kern_rwlock.c:285 > #18 0xb5d5303a in ip_output (m=<value optimized out>, > opt=<value optimized out>, ro=<value optimized out>, > imo=<value optimized out>, inp=<value optimized out>) > at /usr/src/sys/netinet/ip_output.c:313 > #19 0xb5e32028 in check_dyn_rules (chain=0xb6b75068, rt=<value optimized out>, > timer=<value optimized out>) > at /usr/src/sys/netpfil/ipfw/ip_fw_dynamic.c:1522 > #20 0xb5e32a45 in ipfw_dyn_tick (vnetx=0x0) > ---Type <return> to continue, or q <return> to quit--- > at /usr/src/sys/netpfil/ipfw/ip_fw_dynamic.c:1224 > #21 0xb5bd81bc in softclock_call_cc (c=<value optimized out>, > cc=<value optimized out>, direct=<value optimized out>) > at /usr/src/sys/kern/kern_timeout.c:729 > #22 0xb5bd86c0 in softclock (arg=<value optimized out>) > at /usr/src/sys/kern/kern_timeout.c:867 > #23 0xb5b89e6e in intr_event_execute_handlers (p=0xb6aa7e10, > ie=<value optimized out>) at /usr/src/sys/kern/kern_intr.c:1262 > #24 0xb5b8a450 in ithread_loop (arg=<value optimized out>) > at /usr/src/sys/kern/kern_intr.c:1275 > #25 0xb5b8767e in fork_exit (callout=0xb5b8a3c0 <ithread_loop>) > at /usr/src/sys/kern/kern_fork.c:1038 > #26 0xb6140ef0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:286 > Current language: auto; currently minimal > (kgdb) quit > > Command exit status: 0 > Script done on Thu Mar 16 05:28:57 2017 > > -- John Baldwin ----- End Forwarded Message ----- Forwarded to the list as requested.Received on Sat Mar 18 2017 - 02:43:13 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:10 UTC