forked from oxidecomputer/humility
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Ensure that halt_and_read always halts, and reads
I've been tracking down reasons why Humility sometimes gives an inconsistent snapshot of system state in things like the `tasks` output, and I've found one of the culprits. There's this `halt_and_read` function that we use when we want a consistent snapshot. Uses of this function often carry comments like "We read the entire [thing being read] at a go to get as consistent a snapshot as possible." Unfortunately, despite its name, `halt_and_read` doesn't necessarily halt, and this decision is not in control of the caller or obvious to readers of the calling code. The decision to halt is a little complex and depends on... - The target triple -- after discovering an M0 that doesn't support unhalted reads to flash, we appear to have opted out the entire thumbv6m architecture from this meddling. - The exact dynamic call path to reach this point and whether anyone has called halt(), thereby incrementing the `halted` variable (the halt() call _does_ in fact halt; the `op_start` call is similarly shaped but only _maybe_ halts) This behavior has been responsible for a number of bugs I keep hitting when trying to debug _other_ bugs, which is the worst time to be hitting such bugs. This includes - Intermittent failures in archive ID matching on the STM32U5 series, where debugger flash reads are not supported while the CPU is executing (as on the STM32G0, but unlike the STM32H7). - Task status output that is inconsistent, e.g. no tasks showing as runnable or multiple tasks ready but only the idle task actually running. Both of these have had me convinced that we had scheduler bugs; so far it does not appear that we have scheduler bugs, it's just the debugger misrepresenting things. Aside: remember that whether debugger accesses to buses are allowed to race the CPU is a _vendor dependent decision_ that varies from SoC to SoC. It is not consistent on all ARMv6/7/8-M parts; it is not consistent on all parts from ST; it is not consistent on all parts built around the Cortex-M33; it is not consistent across flash, RAM, and peripherals in a single part. Because commercial tools generally don't _do_ this, vendors don't document the specific behavior, and you get to discover it by things failing. In short, doing unhalted reads of anything is asking for flake and should only be done in very specific circumstances. This commit takes a somewhat heavy-handed approach and simply removes the secret unhalted reads behind `halt_and_read`. There may be situations where we legitimately want unhalted reads -- humility dashboard comes to mind -- and IMO these commands should be using an explicit `read_without_halting` operation that is defined as racing, and therefore as "maybe doesn't work on your chip." I have not done that here. Fixes oxidecomputer#527.
- Loading branch information
Showing
7 changed files
with
24 additions
and
72 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters