Date: Tue, 30 Oct 2018 17:09:52 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 228768] EARLY_AP_STARTUP causes panic on amd machines Message-ID: <bug-228768-227-zYqGHVRqLQ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-228768-227@https.bugs.freebsd.org/bugzilla/> References: <bug-228768-227@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=3D228768 John Baldwin <jhb@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kib@FreeBSD.org, | |mjg@FreeBSD.org --- Comment #4 from John Baldwin <jhb@FreeBSD.org> --- Oh, I think I have seen this once before. The issue is that the mtx_lock_spin() code tries to use DELAY(1) and DELAY() is trying to use the "clock_lock" in getit(). In your case, 'tsc_is_invariant' isn't true so DELAY() in sys/x86/x86/delay.c isn't using the TSC. I think the error is probably that we shouldn't be using DELAY(1) in our mu= tex code as it is too high level and/or we should special case DELAY(1) (vs DELAY(n)). Older versions of FreeBSD would map DELAY(1) to just 'inb(0x84)' without talking to the 8254 at all. It looks like i8254_delay() already do= es that when inside of KDB. Also, checking for tsc_is_invariant in DELAY is probably overly-correct. We aren't going to change P-states while we are spinning since we are actively spinning on the CPU. The worst that might happen is that if the CPU were running at a lower clock, we might wait too long. Given how DELAY is used, that's probably better than falling back to a slow timecounter with locks, = etc. --=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-228768-227-zYqGHVRqLQ>