[Bug 204376] Cavium ThunderX system heavily loaded while at db> prompt
brde at optusnet.com.au
Mon Nov 9 06:04:37 UTC 2015
On Mon, 9 Nov 2015 bugzilla-noreply at freebsd.org wrote:
> --- Comment #2 from Conrad E. Meyer <cem at freebsd.org> ---
> If ARM is anything like amd64, it just spinwaits in IPI_STOP (waiting for the
> to be re-enabled). On amd64 you could reduce it to 2 CPUs spinning pretty
> (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
> 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.
More information about the freebsd-bugs