Re: info.0 dump good

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.
> 
> -- 
> 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) _at_
kernel: 2nd 0xc2ca126c syncer (syncer) _at_
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) _at_
kernel: 2nd 0xc0175150 devfs (devfs) _at_
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) _at_ /usr/src/sys/kern/vfs_mount.c:1277
2nd 0xc2ca126c syncer (syncer) _at_ /usr/src/sys/kern/vfs_subr.c:2762