https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228768
John Baldwin <j...@freebsd.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |k...@freebsd.org, | |m...@freebsd.org --- Comment #4 from John Baldwin <j...@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 mutex 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 does 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. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"