RE: RE: RE: [Freeipmi-devel] Using libfreeipmi interface

[Cress, Andrew R]

re: IPMI_LAN_SEQ_NUM_MAX (=0x3F)

As a use case, to understand the problem this causes, one of my
applications 'showsel' allows reading the IPMI SEL.  This can be quite
long on Intel platforms (e.g. 4032 record capacity on one test system
here).  On one test system, with 257 SEL records, the sequence number
increments to 267 (0x10B), and wrapping the sequence number during this
session causes the IPMI chipset to ignore the command with a
duplicate/lower sequence number (and the app/lib would hang).  This
would also affect the fish/sel script/app similarly.  The sequence
number is 32 bits, and incrementing up through that capacity is allowed.
My Tiger (ia64) system isn't up right now, but as I recall, it behaves
the same way.

Where did the 0x3f arbitrary sequence limit come from anyway?  I
couldn't find any reference to sequence number limits in the IPMI spec
or platform specs.

So, my position is that it is not just inappropriate to check sequence
number bounds at 0x3f, but invalid for IPMI 1.5 platforms with LAN
support (a bug).

Andy

-----Original Message-----
From: Albert Chu [mailto:address@hidden 
Sent: Thursday, October 28, 2004 8:04 PM
To: Cress, Andrew R
Cc: address@hidden
Subject: Re: RE: RE: [Freeipmi-devel] Using libfreeipmi interface


> I also found a problem with the  IPMI_LAN_SEQ_NUM_MAX (=0x3F).
> There isn't any precedent in IPMI 1.5 for this, and limiting the 32-
> bitsequence number to 6 bits causes some problems, since the BMC 
> LAN won't handle wrapping the sequence number back to 0 or 1 after 63 
> (0x3f).

I'm not quite convinced this is a problem.  The bounds check makes the
user knowledgeable to the fact that arbitrary sequence numbers aren't
allowed.  I spoke to a few other developers I work with, and they feel
that the bounds checking is more appropriate.  Ab, Ian, Bala, what are
your thoughts??