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
Zdenek,
I think it is easy to overlook that the spec is referring to '0' and not '1'.
I checked the IPMI 2.0 spec and the ipmitool source code and from my point of
view the code is indeed wrong. Inverting of "rsp->data[3]" might solve the
problem.
Regards
Daniel
> -Original Message
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
0x10 == 0x10. :)
I'm getting the
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
>
Hehe, all right.
Ian, I'm just wondering how did you find this bug?
To answer myself what is the meaning of 0x1Fh ~ 0001b. If you
invert it you'll get '1110'. 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 igno
All,
If anyone has an objection to my proposed change to have -m be
all that is
necessary to modify the local IPMB address, let me know by the end of the week.
With the code as currently written, you have to specify both -m
and
-t with both local_address and target_address set to the
exact
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 Styblik
主旨: Re: [Ipmitool-devel] I confuse one thing about "boot info acknowledge" of
