All,
You guys are right, it should be checking the bits for zero and not one. I
had only
verified that it was looking at the right bits.
-- Jim Mankovich | jm...@hp.com (MST) --
On 2/26/2013 6:56 AM, Zdenek Styblik wrote:
> And actually if you convert 0x10, 0x08 etc. into binary you can see
> these have '1' set exactly where it should be missing in the answer
> from BMC in given case. However, I couldn't figure out which logical
> function to use to make it work, resp. to get eg. BMC_value <function>
> 0x10 == 0x10. :)
> I'm getting the feel intention was good, but somebody probably didn't
> check results and what not.
>
> I've already had above written when Daniel Ertel replied. His reply
> makes my feelings about this even stronger and I concur that invert of
> "rsp->data[3]" would solve the problem. But wouldn't be better to use
> values I've posted instead if that's the case?
>
> Couple more things about this code that worry me. Bits 7-5 are
> reserved and should be ignored. They should be set to 1b by BMC as
> well. However, what if BMC violates IPMI spec and has these, or any of
> these three, set to 0? Then '&', or whatever, won't work. Of course,
> one way is to do the work(apply appropriate mask to the rsp->data[3]?)
> and have bits 7-5 either set to 0 or 1. Question is, should we? I'd
> rather bash the vendor for the fix than to mask IPMI stack issues(my
> personal opinion you're free to disagree with).
> Also, cases of 0xFFh and 0x00h aren't handled in the way I would deem
> to be appropriate. And nor is case if there is no match.
> And what is this check ``if ((rsp->data[3]&0x1f) != 0)'' for??? Is it
> a way BMC says: ``Sorry, but nothing is there.''? If so, could
> somebody point me to page in IPMI spec. that say so? And then, perhaps
> add some comment to the code for reference. It could make life much
> easier(imo).
>
> I'm sorry for bringing up even more questions and issues to the table,
> Z.
>
> On Tue, Feb 26, 2013 at 2:05 PM, Zdenek Styblik
> <zdenek.styb...@gmail.com> wrote:
>> Jim,
>>
>> would you care to explain why this isn't a bug and why is it correct,
>> please? Because I don't get it as well and I'd like to know.
>> I sat down, I did binary/hex/whatever thing and came up with the
>> following values for '&' . Order of the values is as in IPMI spec PDF
>> p. 391:
>> * 0xEF - OEM
>> * 0xF7 - SMS
>> * 0xFB - OS
>> * 0xFD - Loader
>> * 0xFE - BIOS
>>
>> Ok, may be I'm going to make an ass out of myself, but even that's a
>> way how to learn and improve.
>> Let's take ``OEM has handled boot info'' case which, I think, is
>> '11101111' in binary. And when you '&' this value with 0x10, which, I
>> believe, is '00010000' in binary, don't you get '0' out of such
>> operation?
>> ~~~
>> 11101111
>> & 00010000
>> =======
>> 00000000
>> ~~~
>>
>> It has been long since high school and I don't practically use this,
>> so it's possible I'm just wrong. It's even possible the code in
>> question works differently, data structure has completely different
>> values and it all makes sense. I have no way how to toy with this in
>> ipmitool, otherwise I would and wouldn't be asking questions.
>> Yeah, it seems to me these conditions are incorrect.
>>
>> And Jim, if you don't know the answers, please, let me know and I'll
>> put more time into it. More than spec, pencil, paper and reading
>> through small and isolated portion of the code. No problems.
>>
>> Thank you for explanation and patience,
>> Z.
>>
>> On Tue, Feb 26, 2013 at 2:06 AM, 國剛 曾 <eva212...@yahoo.com.tw> wrote:
>>>
>>> Hi Jim,
>>>
>>> Thanks for your response.
>>>
>>> In IPMI spec defines that "BIOS/POST has handled boot info" when bit 0 is
>>> 0b.
>>> But in ipmitool, if i set bit 0 is 1b: it display "BIOS/POST has handled
>>> boot info".
>>> That why i think it is not match with IPMI spec. Or that is my
>>> misunderstand, what do you think? Thanks.
>>>
>>>
>>> Ian
>>>
>>> --- 13/2/26 (二)，Jim Mankovich <jm...@hp.com> 寫道：
>>>
>>>
>>> 寄件者: Jim Mankovich <jm...@hp.com>
>>> 主旨: Re: [Ipmitool-devel] I confuse one thing about "boot info acknowledge"
>>> of System Boot Options Command
>>> 收件者: "國剛 曾" <eva212...@yahoo.com.tw>
>>> 副本: Ipmitool-devel@lists.sourceforge.net
>>> 日期: 2013年2月26日,二,上午6:17
>>>
>>>
>>> lan,
>>>
>>> It looks correct to me.
>>>
>>> Why do you believe it does not match the IPMI spec.
>>>
>>> The spec states bit 0 is BIOS/POST has handled boot info and
>>> the code look at bit 0 by using a mask of 0x1 == 0x1
>>>
>>> -- Jim Mankovich | jm...@hp.com --
>>>
>>> On 2/25/2013 2:03 AM, 國剛 曾 wrote:
>>>
>>> Dear all,
>>>
>>> I confuse one thing.
>>>
>>> In function "ipmi_chassis_get_bootparam" of ipmi_chass.c define:
>>> case 4:
>>> {
>>> printf( " Boot Info Acknowledge :\n");
>>> if((rsp->data[3]&0x1f) != 0)
>>> {
>>> if((rsp->data[3]&0x10) == 0x10)
>>> printf(" - OEM has handled boot info\n");
>>> if((rsp->data[3]&0x08) == 0x08)
>>> printf(" - SMS has handled boot info\n");
>>> if((rsp->data[3]&0x04) == 0x04)
>>> printf(" - OS // service partition has handled boot
>>> info\n");
>>> if((rsp->data[3]&0x02) == 0x02)
>>> printf(" - OS Loader has handled boot info\n");
>>> if((rsp->data[3]&0x01) == 0x01)
>>> printf(" - BIOS/POST has handled boot info\n");
>>> }
>>> else
>>> {
>>> printf(" No flag set\n");
>>> }
>>> }
>>>
>>>
>>> But in IPMI spec 2.0 sefine:
>>> [7] - reserved. Write as 1b. Ignore on read.
>>> [6] - reserved. Write as 1b. Ignore on read.
>>> [5] - reserved. Write as 1b. Ignore on read.
>>> [4] - 0b = OEM has handled boot info.
>>> [3] - 0b = SMS has handled boot info.
>>> [2] - 0b = OS / service partition has handled boot info.
>>> [1] - 0b = OS Loader has handled boot info.
>>> [0] - 0b = BIOS/POST has handled boot info.
>>>
>>>
>>> So, these are not match. So, it's ipmitool bug or my misunderstand.
>>> Could someone help me? Thanks.
>>>
>>>
>>>
>>> Ian
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_d2d_feb
>>>
>>>
>>>
>>> _______________________________________________
>>> Ipmitool-devel mailing list
>>> Ipmitool-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_d2d_feb
>>> _______________________________________________
>>> Ipmitool-devel mailing list
>>> Ipmitool-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
>>>
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
