Date: Sat, 10 Feb 2018 23:59:22 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 225450] 11.1-* panics on AMD Opteron 2k due to EARLY_AP_STARTUP Message-ID: <bug-225450-8-bq3arWjWH6@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-225450-8@https.bugs.freebsd.org/bugzilla/> References: <bug-225450-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D225450 --- Comment #11 from John Baldwin <jhb@FreeBSD.org> --- Hmm, I don't know why the previous simple lock didn't help. One other poss= ible thing to try is placing 'while (1);' infinite loop in the init_secondary_ta= il() function in sys/x86/x86/mp_x86.c and moving it around in the function to na= rrow down when the APs are triggering the double fault (which is a stack overflo= w).=20 If you put the while(1) before the smp_cpus++; the failure mode you should = see if the AP doesn't fault is a 'panic AP #x failed to start'. After the smp_cpus++ line you should at least no longer get the double fault panic if= you haven't hit the double fault yet. Another thought is that it might be there is a missing MFC in 11 related to= one or more kthreads starting too early. You could perhaps build a kernel with: options KTR_COMPILE=3DKTR_PROC options KTR_MASK=3DKTR_PROC options KTR_VERBOSE And see what messages are logged before the crash (to see if the APs are starting to run other kthreads besides the idle thread). --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-225450-8-bq3arWjWH6>