Panic + stack overflow in i2c_driver on c71
#2004
Comments
|
The stack overflow can't be detected statically because Robert pointed out that we have a handful of unresolved I2C glitches already filed: #1821, #1822, #1823, #1824. It's possible that one of these glitches is interacting badly with the new SSD controller IC. |
mkeeter
added a commit
that referenced
this issue
Feb 11, 2025
In some cases, the deepest stack involves a tail call. For example, consider `write_fmt`, which has no stack of its own and branches directly to `core::fmt::write` (instead of using `bl`): ```asm 0804a704 <core::fmt::Write::write_fmt>: 804a704: 460a mov r2, r1 804a706: 6849 ldr r1, [r1, #4] 804a708: 2901 cmp r1, #1 804a70a: bf18 it ne 804a70c: 2900 cmpne r1, #0 804a70e: 4901 ldr r1, [pc, #4] ; (804a714 <core::fmt::Write::write_fmt+0x10>) 804a710: f7ff ba68 b.w 8049be4 <core::fmt::write> 804a714: 0804b024 .word 0x0804b024 ``` This PR adds basic tail call support to the disassembler. The main effect is adding 80 bytes to panic stack depth. Before: ``` udprpc: 2464 bytes (limit is 4096) [+8] _start [+2264] main [+16] core::array::<impl core::ops::index::IndexMut<I> for [T; N]>::index_mut [+16] <core::ops::range::Range<usize> as core::slice::index::SliceIndex<[T]>>::index_mut [+56] core::slice::index::slice_end_index_len_fail [+40] core::panicking::panic_fmt [+56] rust_begin_unwind [+8] userlib::sys_panic_stub ``` After: ``` udprpc: 2544 bytes (limit is 4096) [+8] _start [+2264] main [+16] core::array::<impl core::ops::index::IndexMut<I> for [T; N]>::index_mut [+16] <core::ops::range::Range<usize> as core::slice::index::SliceIndex<[T]>>::index_mut [+56] core::slice::index::slice_end_index_len_fail [+40] core::panicking::panic_fmt [+56] rust_begin_unwind [+0] core::fmt::Write::write_fmt [+88] core::fmt::write ``` Unfortunately, this _does not_ detect the stack overflow in #2004, which happens during dynamic dispatch. Still, it's a step in the right direction!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
On
cadbury:c71, @rmustacc noticed Gimlet Issues when he connected a particular driver (??).The
thermal,gimlet_seqandi2c_drivergeneration counts are spinning up:The actual crash is a stack overflow in
i2c_driver, which is seemingly not found by our static detector (#1890). In the dump, it seems like it's an overflow while panicking, but I can't make sense of the full trace:(note that this is using
--guessto use the saved frame pointer, so we may be able to stare at the memory by hand)The I2C ringbuf shows a call to
stm32xx_i2c::panic, which logged the whole state and then panicked:Cores are in
/staff/cores/hubris-2004/The text was updated successfully, but these errors were encountered: