+14
−0
Loading
A truncated response, caused by host power-off, or other conditions, can lead to message desynchronization. Raw trace data (STOP loss scenario, add state transition comment): 1. T-1: Read response phase (SSIF_RES_SENDING) 8271.955342 WR_RCV [03] <- Read polling cmd 8271.955348 RD_REQ [04] <== SSIF_RES_SENDING <- start sending response 8271.955436 RD_PRO [b4] 8271.955527 RD_PRO [00] 8271.955618 RD_PRO [c1] 8271.955707 RD_PRO [00] 8271.955814 RD_PRO [ad] <== SSIF_RES_SENDING <- last byte <- !! STOP lost (truncated response) 2. T: New Write request arrives, BMC still in SSIF_RES_SENDING 8271.967973 WR_REQ [] <== SSIF_RES_SENDING >> SSIF_ABORTING <- log: unexpected WR_REQ in RES_SENDING 8271.968447 WR_RCV [02] <== SSIF_ABORTING <- do nothing 8271.968452 WR_RCV [02] <== SSIF_ABORTING <- do nothing 8271.968454 WR_RCV [18] <== SSIF_ABORTING <- do nothing 8271.968456 WR_RCV [01] <== SSIF_ABORTING <- do nothing 8271.968458 WR_RCV [66] <== SSIF_ABORTING <- do nothing 8271.978714 STOP [] <== SSIF_ABORTING >> SSIF_READY <- log: unexpected SLAVE STOP in state=SSIF_ABORTING 3. T+1: Next Read polling, treated as a fresh transaction 8271.979125 WR_REQ [] <== SSIF_READY >> SSIF_START 8271.979326 WR_RCV [03] <== SSIF_START >> SSIF_SMBUS_CMD <- smbus_cmd=0x03 8271.979331 RD_REQ [04] <== SSIF_RES_SENDING <- sending response 8271.979427 RD_PRO [b4] <- !! this is T's stale response -> desynchronization When in SSIF_ABORTING state, a newly arrived command should still be handled to avoid dropping the request or causing message desynchronization. Fixes: dd2bc5cc ("ipmi: ssif_bmc: Add SSIF BMC driver") Signed-off-by:Jian Zhang <zhangjian.3032@bytedance.com> Message-ID: <20260403090603.3988423-3-zhangjian.3032@bytedance.com> Signed-off-by:
Corey Minyard <corey@minyard.net>