RE: [Freeipmi-devel] Re: Fujitsu's SDR cache bug

[Albert Chu]

Hey Holger,

(BTW, I'm splitting this thread into two, so the response to the other
part is in the original thread).

On Tue, 2010-08-17 at 08:14 -0700, Liebig, Holger wrote:
> > 
> > Hi Dan,
> > 
> > > In the fact, it would be better to use the function as part of
> > > interpret-oem-data within ipmi-sel, but it require better knowledge of
> > > current implementation of ipmi-sel than I have. Someone with better
> > > skills may implement it (using the code from patch). Then I can help
> > > with testing, if necessary.
> > 
> > I had intended to add this into ipmi-sel, but w/o a mobo to test on I
> > let it pass.  If you're game to test a patch for me, I'd be glad to
> > implement it into ipmi-sel.  I'm busy right now, so it may take some
> > time for me to get a patch together.
> 
> I can try to understand/dive into ipmi-sel and come up with something
> for review. This would definitely be the better place to implement
> this feature. 
> But first I have to find an issue with the SDR cache: Al any idea why
> Get SDR might try to read only 5 Bytes from Offset 0 instead of the
> previous 16bytes when reading the last record 1770 (see attached debug
> output)?

The attachment got dropped by my filters, so I'll have to take a guess
for now (if you can resend w/ just the last few K of the debug dump,
that should be enough for me to figure it out.  Or alternately, passing
--enable-debug and --enable-trace to ./configure can get a detailed
trace).

I'm not quite sure what you meant by "5 Bytes from Offset 0 instead of
the previous 16bytes" (perhaps it's an obvious bug that the debug dump
would show).  The 5 bytes is likely the "read" of the SDR header.  So if
it fails on record 1770, perhaps there is something kooky in the header
that FreeIPMI bails on?

Al

> > 
> > Short term, I think we can add this patch into ipmi-oem as an extra OEM
> > option for Fujitsu motherboards.
> > 
> > BTW, what mobo are you running this on, so I can document in the future.
> > 
> 
> This feature/OEM command is available on all current BMC's from Fujitsu, even 
> on the previous generation. The intention is to provide a consistent SEL 
> translation and severity assignment across different tools. This also works 
> for time stamped OEM SEL entries which we use for a limited auditing (e.g. 
> login or power control from IP a.b.c.d). 
> Unfortunately due to memory constrains in the previous BMC generation the 
> maximum length of a single response is limited to 64bytes, while on the 
> current product line you should be able to get the full 100bytes translated 
> SEL text with a single request at least over LAN. Maximum (non standard) KCS 
> transfer size is also different between current (255) and previous (64) 
> generation, so the code should compare the data received with the total 
> length reported in the response. 
> 
> If you want to double check for support of this OEM command beforehand, you 
> can evaluate the Get Device Id response:
> Vendor ID: 0x2880
> ProductId: should be >= 0x0200
> 
> Holger
> 
-- 
Albert Chu
address@hidden
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory