On Mon, 9 Nov 2015 [email protected] wrote:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204376 --- Comment #2 from Conrad E. Meyer <[email protected]> --- 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 _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
