Date: Mon, 07 Sep 2020 06:34:33 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 249149] panic: -CURRENT with KCSAN option -> panic: mtx_lock_spin: recursed on non-recursive mutex et_hw_mtx @ src/sys/kern/kern_clocksource.c:850 Message-ID: <bug-249149-227-7Y4lrPl2ZG@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-249149-227@https.bugs.freebsd.org/bugzilla/> References: <bug-249149-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249149 --- Comment #2 from Jason A. Harmening <jah@FreeBSD.org> --- It looks like this is a KCSan false positive on the LAPIC MMIO mapping. Since this is a guest that doesn't use the x2APIC (and therefore must use MMIO for LAPIC access instead of MSRs), all CPUs will share the same LAPIC mapping. However, the underlying physical access will be routed to the local CPU's APIC, so multiple CPUs aren't actually racing on the same hardware resource. Or at least I hope that's the source of the problem, otherwise Hyper-V really misconfigured the guest. Since the LAPIC access happens in the course of configuring an event timer, and the KCSan warning printf itself tries to configure a callout, we get the panic. Can you try the attached (build-tested only) patch? -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-249149-227-7Y4lrPl2ZG>