On 07/05/2018 12:12, Hans Petter Selasky wrote:
On 07/05/18 20:59, Hans Petter Selasky wrote:
On 07/05/18 19:48, Pete Wright wrote:
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 :(
Hi,
The problem may be that the patch to enable atomic inlining of all
macros forgot to set the SMP keyword which means SMP is not defined
at all for KLD's so all non-kernel atomic usage is with MPLOCKED empty!
/*
* For userland, always use lock prefixes so that the binaries will run
* on both SMP and !SMP systems.
*/
#if defined(SMP) || !defined(_KERNEL)
#define MPLOCKED "lock ; "
#else
#define MPLOCKED
#endif
Can you try to recompile the LinuxKPI /sys/modules/linuxkpi with
DEBUG_FLAGS="-DSMP" ?
and similarly the drm-next package?
Also please find attached a patch for amd64.
i have been running this patch for about 4hours. previous uptime before
this patch was under 1hr. i've attached and detached HDMI displays and
gone through several suspend/resume cycles as well without any issues.
to be clear - since i'm not sure this is was your intent - i applied the
patch, rebuilt/installed a new kernel. i did *not* use the "-DSMP"
flags for linuxkpi or the drm-next module.
cheers,
-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"
