Date: Mon, 9 Nov 2015 17:04:29 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> Cc: freebsd-bugs@freebsd.org Subject: Re: [Bug 204376] Cavium ThunderX system heavily loaded while at db> prompt Message-ID: <20151109162405.M969@besplex.bde.org> In-Reply-To: <bug-204376-8-cSABijm8UW@https.bugs.freebsd.org/bugzilla/> References: <bug-204376-8@https.bugs.freebsd.org/bugzilla/> <bug-204376-8-cSABijm8UW@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 9 Nov 2015 bugzilla-noreply@freebsd.org wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204376 > > --- Comment #2 from Conrad E. Meyer <cem@freebsd.org> --- > If ARM is anything like amd64, it just spinwaits in IPI_STOP (waiting for the > CPU > to be re-enabled). On amd64 you could reduce it to 2 CPUs spinning pretty > easily > (hlt any non-panic and non-BSP core -- they'll never be needed until reboot). > But that still leaves 2 CPUs spinning. > > The patch attempted to hlt all non-panic CPUs in IPI_STOP, but leave interrupts > enabled so they could be woken again. This does Not Work Well in panic context > (I forget the details, but if you've paniced you really don't want normal > interrupt > code running on the non-ddb CPU(s)). Enabling normal interrupts breaks ddb context too. ddb is already broken in restarting other CPUs when it single steps. This usually enables interrupts on other CPUs (if not the current one), so the state might be completely different after you step a single instruction. Just like it might be in normal operation for unlocked states, but more so since in normal operation the single instruction runs in a few cycle but for single stepping it takes thousands or millions of cycles in real time (and the other CPUs run many of thos cycles in real time after they are restarted before they are stopped again). But it is inconvenient for the state that you are trying to debug to change much. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151109162405.M969>