Re: [Openipmi-developer] [PATCH 0/1] ipmi: Fix issues with BMCs that report event and message incorrectly

From: Jian Zhang

Date: Wed Apr 22 2026 - 00:46:43 EST


> 2026年4月22日 06:24,Matt Fleming <matt@xxxxxxxxxxxxxxxx> 写道:
>
> On Tue, Apr 21, 2026 at 07:42:42AM -0500, Corey Minyard wrote:
>> Matt reported that there were issues with the IPMI driver getting wedged
>> in some cases. It turns out that the BMC was not reporting an error as
>> it should have (per the spec) when the event queue was empty. The IPMI
>> driver would then request the next event, and so on, wedging the driver.
>
> Thanks for replying so quickly, Corey. I'll test these out.
>
> One bit of info I pulled out of the stuck machine is that the response
> looks properly formed.
>
> I sampled the first 8 entries and they were all identical 19-byte
> successful READ_EVENT_MSG_BUFFER responses:
>
> 1c 35 00 55 55 c0 41 a7 00 00 00 00 00 3a ff 00 ff ff ff
>

Perhaps I know where this data comes from.
During a previous debugging session (where ipmitool v1.8.19 failed on sensor list due to an underflow in
nr_numbers, which has since been fixed), I noticed this behavior. However, I
’m not sure why it is implemented this way or what exactly this command is intended to do.
If you are running on OpenBMC, it is very likely related to this part,
where a fixed value is always returned (especially if the KCS channel happens to be configured as 15):

See: https://github.com/openbmc/phosphor-host-ipmid/blob/master/systemintfcmds.cpp#L35

Jian.

> So on this machine, the event replies do not look short or malformed;
> they look like repeated successful event-buffer reads with the same
> payload.
>
> Thanks,
> Matt
>
>
> _______________________________________________
> Openipmi-developer mailing list
> Openipmi-developer@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/openipmi-developer