Fwd: Re: info.0 dump good
- Start Forwarded Message - Sent: Fri, 17 Mar 2017 12:47:30 -0700 From: John Baldwin To: jbt...@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 wrote: > > > On Monday, March 13, 2017 06:49:05 PM Jeffrey Bouquet wrote: > > > > > > On Mon, 13 Mar 2017 14:04:23 -0700, John Baldwin 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@ .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) @ /usr/src/sys/kern/vfs_mount.c:1277 > 2nd 0xbfb90150 syncer (syncer) @ /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 __lock
Re: info.0 dump good
On Mon, 13 Mar 2017 14:04:23 -0700, John Baldwin 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. > > -- > John Baldwin Sent the core.text.8 question, as not a kgbd expert, pending, earlier today, not to the list: Now to the list, one of several daily backtraces, and/or lock order reversals, in dmesg, starting X, mounting or unmounting 2nd disks... this from /var/log/messages... kernel: lock order reversal: kernel: 1st 0xc21ebd84 ufs (ufs) @ kernel: 2nd 0xc2ca126c syncer (syncer) @ kernel: stack backtrace: kernel: #0 0xb5c22421 at witness_debugger+0x81 kernel: #1 0xb5c22342 at witness_checkorder+0xd12 kernel: #2 0xb5b9b5d4 at __lockmgr_args+0xa64 kernel: #3 0xb5c784ad at vop_stdlock+0x4d kernel: #4 0xb618e7f7 at VOP_LOCK1_APV+0xd7 kernel: #5 0xb5c9c137 at _vn_lock+0xb7 kernel: #6 0xb5c8b00a at vputx+0x16a kernel: #7 0xb5c8286c at dounmount+0x5 kernel: dc kernel: #8 0xb5c82185 at sys_unmount+0x315 kernel: #9 0xb6155fa5 at syscall+0x3b5 kernel: #10 0xb6140ede at Xint0x80_syscall+0x2e kernel: lock order reversal: kernel: 1st 0xc21ebd84 ufs (ufs) @ kernel: 2nd 0xc0175150 devfs (devfs) @ kernel: stack backtrace: kernel: #0 0xb5c22421 at witness_debugger+0x81 kernel: #1 0xb5c22342 at witnes kernel: s_checkorder+0xd12 kernel: #2 0xb5b9b5d4 at __lockmgr_args+0xa64 kernel: #3 0x kernel: b5c784ad at vop_stdlock+0x4d kernel: #4 0xb618e7f7 at VOP_LOCK1_APV+0xd7 kernel: #5 0xb5c9c137 at _vn_lock+0x kernel: b7 kernel: #6 0xb5eb9617 at ffs_flushfiles+0x157 kernel: #7 0xb5e9d9aa at soft kernel: dep_flushfiles+0x17a kernel: #8 0xb5ebc04c at ffs_unmount+0x7c kernel: #9 0xb5 kernel: c8299b at dounmount+0x70b kernel: #10 0 kernel: xb5c82185 at sys_unmount+0x315 kernel: #11 0xb6155fa5 at syscall+0x3b5 kernel: kernel: #12 0xb6140ede at Xint0x80_syscall+0x2e from the following two files: 1st 0xc21ebd84 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1277 2nd 0xc2ca126c syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2762 ___ 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: info.0 dump good
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. -- 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"
