On 07/05/2018 10:10, John Baldwin wrote:
On 7/3/18 5:10 PM, Pete Wright wrote:
On 07/03/2018 15:56, John Baldwin wrote:
On 7/3/18 3:34 PM, Pete Wright wrote:
On 07/03/2018 15:29, John Baldwin wrote:
That seems like kgdb is looking at the wrong CPU. Can you use
'info threads' and look for threads not stopped in 'sched_switch'
and get their backtraces? You could also just do 'thread apply
all bt' and put that file at a URL if that is easiest.
sure thing John - here's a gist of "thread apply all bt"
https://gist.github.com/gem-pete/d8d7ab220dc8781f0827f965f09d43ed
That doesn't look right at all. Are you sure the kernel matches the
vmcore? Also, which kgdb version are you using?
yea i agree that doesn't look right at all. here is my setup:
$ which kgdb
/usr/bin/kgdb
$ kgdb
GNU gdb 6.1.1 [FreeBSD]
$ ls -lh /var/crash/vmcore.1
-rw------- 1 root wheel 1.6G Jul 3 15:03 /var/crash/vmcore.1
$ ls -l /usr/lib/debug/boot/kernel/kernel.debug
-r-xr-xr-x 1 root wheel 87840496 Jul 3 13:54
/usr/lib/debug/boot/kernel/kernel.debug
and i invoke kgdb like so:
$ sudo kgdb /usr/lib/debug/boot/kernel/kernel.debug /var/crash/vmcore.1
here's a gist of my full gdb session:
http://termbin.com/krsn
dunno - maybe i have a bad core dump? regardless, more than happy to
help so let me know if i should try anything else or patches etc..
Can you try installing gdb from ports and using /usr/local/bin/kgdb?
that seems to have done the trick, at least the output looks more
encouraging.
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
__curthread () at ./machine/pcpu.h:231
231 __asm("movq %%gs:%1,%0" : "=r" (td)
here's my full kgdb session:
http://termbin.com/qa4f
i don't see any threads not in "sched_switch" though :(
-pete
--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA
_______________________________________________
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"
