On 6/2/06, Philip Pokorny <[EMAIL PROTECTED]> wrote:
I'm having a problem with the latest kernels not allowing me to
communicate over the IPMB bus.

I've been testing the latest Fedora, Red Hat 4 and SLES 10 (Beta/Release
candidates) kernels and they have all started failing with the most
recent versions.

The symptom is that when I attempt to send a message over the IPMB I get
the following error:

linux-0w10:~ # ipmitool -m 142 -t 32 bmc info
Unable to send command: Invalid argument
Get Device ID command failed

I have drilled down through the code and found that the reason is that
the code that identifies the channels is receiving something it doesn't
expect from my BMC and marking channel 0 as unavailable and therefore
messages addressed to the IPMB are denied as "invalid argument".

The hardware I am testing is somewhat like an ATCA in that I have on
chassis with 12 server blades and two management/networking blades.  The
BMC on the server blades and the management blade communicate over a
IPMB to effect management of the chassis.  The chassis is a Penguin
Computing BladeRunner.

In my reading of the spec, channel 0 is always and only an IPMB bus.
Therefore, I have written a patch that forces this assumption, while
keeping the rest of the channel scanning logic.  I have tried to
simplify the scanning logic.  Also, I have modified the code to *not*
scan channels 8-14 which are reserved or special.

On my  hardware there are two IPMB busses channel 0 and channel 3
[EMAIL PROTECTED]:/home/raghu/exp# ipmitool channel info 0x0
Channel 0x0 info:
  Channel Medium Type   : IPMB (I2C)
  Channel Protocol Type : IPMB-1.0
  Session Support       : session-less
  Active Session Count  : 0
  Protocol Vendor ID    : 7154
[EMAIL PROTECTED]:/home/raghu/exp# ipmitool channel info 0x3
Channel 0x3 info:
  Channel Medium Type   : IPMB (I2C)
  Channel Protocol Type : IPMB-1.0
  Session Support       : session-less
  Active Session Count  : 0
  Protocol Vendor ID    : 7154

 

The attached patch is against the SLES 10 Release Candidate 2
(2.6.16-xxx) kernel.  I'll happily rebase it against some other kernel
tree if you can tell me what tree you would prefer the patch against.

With it applied, I get the following output when loading the ipmi
drivers.  I've enabled DEBUG_MSGING so that the actual messages
sent/received are printed out.

> ipmi message handler version 38.1
> IPMI System Interface driver.
> ipmi_si: Found SMBIOS-specified state machine at I/O address 0xca2,
> slave address 0x20
> Send: 18 42 01
> Recv: 1c 42 ff
> Send: 18 42 02
> Recv: 1c 42 d3
> Send: 18 42 03
> Recv: 1c 42 ff
> Send: 18 42 04
> Recv: 1c 42 00 04 0c 05 00 f2 1b 00 00 00
> Send: 18 42 05
> Recv: 1c 42 d3
> Send: 18 42 06
> Recv: 1c 42 ff
> Send: 18 42 07
> Recv: 1c 42 d3
> Send: 18 42 0f
> Recv: 1c 42 ff
>  IPMI kcs interface initialized
> ipmi device interface


You can see that the BMC is replying with 'ff' as the status.  It does
this when queried about channel 0 as well, but not all the time. (but
probably 95% of the time)  I am working with the BMC code to try and
figure out why it's responding with 'ff', but the attached patch
resolves the primary pain I have now where I can't manage the chassis
because I can't send messages over the IPMB.

Thanks,
:v)

--
Philip Pokorny, Director of Engineering
Tel: 415-370-0835   Fax: 415-954-2899   Toll Free: 888-PENGUIN
PENGUIN COMPUTING, INC.
www.penguincomputing.com





_______________________________________________
Openipmi-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openipmi-developer






--
I AM AGAINST THE CURRENT RESERVATION POLICY!
http://youth4equality.org
http://savebrandindia.org
Raghavendra G
Software Engineer,
Clovis Solutions, Bangalore
+91 9880213025
_______________________________________________
Openipmi-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Reply via email to