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/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D249149 --- Comment #2 from Jason A. Harmening <jah@FreeBSD.org> --- It looks like this is a KCSan false positive on the LAPIC MMIO mapping. Si= nce 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.= =20 However, the underlying physical access will be routed to the local CPU's A= PIC, 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 pa= nic. Can you try the attached (build-tested only) patch? --=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-249149-227-7Y4lrPl2ZG>