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 updating the ROM on a Gimlet Rev B, the i2c_driver was seen to have panicked. (Due to a to-be-filed issue, this caused the thermal loop to be unable to assert control of the system, which in turn caused the fans to watchdog.)
Unfortunately, due to another Humility bug (also to-be-filed!), we neglected to get 0x080aafcc, 0x080aad44, and 0x080aad4c in the dump -- but there is only one panic! in FixedMap::insert:
////// Inserts the `value` into the map for the specified `key`. If the/// specified key already exists in the map, its value will be overwritten/// with the specified value. It is up to the caller to assure that there/// is room in the map; if the map is full, this code will panic.///pubfninsert(&mutself,key:K,value:V){for i in0..self.contents.len(){matchself.contents[i]{None => {self.contents[i] = Some((key, value));return;}Some((k, _)) => {if k == key {self.contents[i] = Some((key, value));return;}}}}panic!("FixedMap overflow");}
Knowing that this is (likely) a FixedMap overflow, the cause becomes clear when looking at the ring buffer:
$ humility manifest
...
i2c buses => 4 controllers, 5 buses
C PORT MODE NAME DESCRIPTION
1 B trgt spd SPD proxy
2 B init m2 M.2 bus
2 F init front Front bus
3 H init mid Mid bus
4 F init rear Rear bus
...
So we have seen resets to two different busses (front bus and mid bus) -- almost certainly because we were preempted by the SPI driver blasting the hostflash image. The problem is not the bus resets -- it is that we are always setting a bus to be in the MuxState::Unknown in the reset path, but in fact the map only has room for the busses that actually have muxes. In this case, because we have been to A0, the m2 bus has a mux set (that is, it has mux state); when we add front bus, the map is full -- and when we (errantly) add mid bus, we overflow. The fix is to only set the mux state to be MuxState::Unknown if a bus, in fact, has a mux to begin with.
The text was updated successfully, but these errors were encountered:
In updating the ROM on a Gimlet Rev B, the
i2c_driver
was seen to have panicked. (Due to a to-be-filed issue, this caused the thermal loop to be unable to assert control of the system, which in turn caused the fans to watchdog.)Here is the i2c_driver dump as taken by Jefe. We died because of a stack overflow:
Looking at the stack, we overdflowed while panicking:
Our panic buffer is (unsurprisingly) incomplete:
But we are at the call to
panic
infixedmap::FixedMap<K,V,_>::insert
:Unfortunately, due to another Humility bug (also to-be-filed!), we neglected to get
0x080aafcc
,0x080aad44
, and0x080aad4c
in the dump -- but there is only onepanic!
inFixedMap::insert
:Knowing that this is (likely) a
FixedMap
overflow, the cause becomes clear when looking at the ring buffer:Here are the busses:
So we have seen resets to two different busses (
front
bus andmid
bus) -- almost certainly because we were preempted by the SPI driver blasting the hostflash image. The problem is not the bus resets -- it is that we are always setting a bus to be in theMuxState::Unknown
in the reset path, but in fact the map only has room for the busses that actually have muxes. In this case, because we have been to A0, them2
bus has a mux set (that is, it has mux state); when we addfront
bus, the map is full -- and when we (errantly) addmid
bus, we overflow. The fix is to only set the mux state to beMuxState::Unknown
if a bus, in fact, has a mux to begin with.The text was updated successfully, but these errors were encountered: