Ian, you're welcome. Keep up reading/studying and reporting bugs!
FYI to others, I've logged SF.net ticket for this bug. Link is: https://sourceforge.net/tracker/?func=detail&aid=3606115&group_id=95200&atid=610550 Thanks, Z. On Wed, Feb 27, 2013 at 2:27 AM, 國剛 曾 <eva212...@yahoo.com.tw> wrote: > > Hi all, > > Thanks for your response. > > Hi Zdenek, > > I just want to study this command. Then I try it and find out it. And > thanks for your response and explain. > > > > ian > > --- 13/2/27 (三)，Zdenek Styblik <zdenek.styb...@gmail.com> 寫道： > > > 寄件者: Zdenek Styblik <zdenek.styb...@gmail.com> > > 主旨: Re: [Ipmitool-devel] I confuse one thing about "boot info acknowledge" > of System Boot Options Command > 收件者: "Jim Mankovich" <jm...@hp.com> > 副本: "國剛 曾" <eva212...@yahoo.com.tw>, Ipmitool-devel@lists.sourceforge.net, > daniel.er...@advantech.eu > 日期: 2013年2月27日,三,上午1:25 > > > 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
