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