You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In debugging an unrelated issue, we noticed some Sidecar sequencer panics.
It turns out, the sidecar sequencer contains a lot of deliberate panics as a very expensive way of performing a loop. We have better tools for this that don't take the system down for a dump and distract engineers:
A loop (which is what I would strongly recommend)
The Jefe::restart_me operation is how you do a deliberate restart without a dump.
The text was updated successfully, but these errors were encountered:
It's probably also worth going through and thinking a bit about whether any of these panics are places where we should just reset a particular component and retry the particular operation that failed, or if they all really require starting the whole thing over from the top. The Gimlet sequencer task retries individual I2C transactions in a number of places instead of starting back at the top of the initialization process, and I wonder if it would make sense to borrow that here?
Of course, I'm not familiar enough with the sidecar startup process to know which operations can be retried individually, and which require resetting everything and starting over, but it might be worth thinking about for someone who does have a sense of that...
In debugging an unrelated issue, we noticed some Sidecar sequencer panics.
It turns out, the sidecar sequencer contains a lot of deliberate panics as a very expensive way of performing a loop. We have better tools for this that don't take the system down for a dump and distract engineers:
loop
(which is what I would strongly recommend)Jefe::restart_me
operation is how you do a deliberate restart without a dump.The text was updated successfully, but these errors were encountered: