Hehe, all right.
Ian, I'm just wondering how did you find this bug?
To answer myself what is the meaning of 0x1Fh ~ 00011111b. If you
invert it you'll get '11100000'. In other words, it's handle for 0x00h
case. I got it on my way home thinking about it and those three bits
you're supposed to ignore on read and all.
Anyway. I'm also sorry for crappy English in my previous e-mail. I
should've triple checked whether it makes sense and whether it has all
words and all.
Thanks (to all),
Z.
On Tue, Feb 26, 2013 at 5:06 PM, Jim Mankovich <jm...@hp.com> wrote:
> 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
