Date: Fri, 8 Jun 2018 09:34:42 -0700 From: Matthew Macy <mmacy@freebsd.org> To: Mark Johnston <markj@freebsd.org> Cc: src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r334827 - in head/sys: amd64/amd64 arm/arm dev/hwpmc i386/i386 kern mips/atheros mips/cavium powerpc/powerpc sys Message-ID: <CAPrugNqShOCJ6S0CEhkT-ayM2bVhZ14fBsio3Pyaiz0-qFvw8Q@mail.gmail.com> In-Reply-To: <20180608162701.GA65388@pesky> References: <201806080458.w584w3rn006318@repo.freebsd.org> <20180608143448.GB57885@pesky> <CAPrugNrHh59QmFPAxhA0OUXnNe38EWqwDF9gFs=PeMB7fbOt-w@mail.gmail.com> <20180608162701.GA65388@pesky>
next in thread | previous in thread | raw e-mail | index | archive | help
> The fact that our NMI handler isn't re-entrant can lead to subtle > problems. If while executing the NMI handler we hit a dtrace > probe or DDB breakpoint, the iret executed upon return to the handler > will re-enable NMIs. Then, if a second NMI arrives before the handler > for the first has returned, the trapframe will be clobbered. Did you > rule out an issue like this? No, but it happened instantly on all CPUs an a non-debug kernel 100% of the time after I changed pmc_process_interrupt earlier this week. My voodoo fix now avoids it. What you're describing sounds episodic and doesn't sound like it would be fixed / worked around by my change. -M
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPrugNqShOCJ6S0CEhkT-ayM2bVhZ14fBsio3Pyaiz0-qFvw8Q>