Jan Safranek wrote: > On 02/04/2010 03:41 PM, Corey Minyard wrote: >> IIRC, the address in question is 0xc2, and the from below the address of >> the local card is 0xc2. So if the SDR has the wrong address, it's not >> going to work. > > It could work if ipmitool knows the local address. My question is, how > to get it from /dev/ipmi? Both IPMICTL_GET_MY_ADDRESS_CMD and > IPMICTL_GET_MY_CHANNEL_ADDRESS_CMD (with channel 0xf) return 0x20. I > want 0xc2... Do I really have to parse /dev/ipmi/*/params? You need to use channel 0, not channel 0xf. a slave address is meaningless with channel 0xf. I just tested it and it works fine for me with IPMICTL_GET_MY_ADDRESS_CMD and IPMICTL_GET_MY_CHANNEL_ADDRESS with channel 0.
-corey > > Jan > > > >> >> And I was wrong, the driver does not detect that an IPMB message is to >> the local address and route it properly. So ipmitool will need to know. >> -corey >> >> Jan Safranek wrote: >>> On 02/04/2010 12:09 AM, Corey Minyard wrote: >>>> You can also change it in the IPMI driver and I believe that will >>>> work, >>>> too. Doing this requires writing a little software to call the >>>> ioctl to >>>> do this, or writing a little script. The script is harder than it >>>> should >>>> be, you have to hot remove the device and hot add it with a different >>>> address. The address information is at /proc/ipmi/0/params. Mine looks >>>> like: >>>> >>>> i2:~# cat /proc/ipmi/0/params >>>> kcs,i/o,0xca2,rsp=1,rsi=1,rsh=0,irq=0,ipmb=32 >>> >>> hmmm, mine *already is*: >>> kcs,i/o,0xca8,rsp=4,rsi=1,rsh=0,irq=0,ipmb=194 >>> (194 = 0xc2) >>> >>> I have not changed anything, just service ipmi start. I admit I don't >>> know how the kernel driver works and how it's configured - how did it >>> detect it's not 0x20? I use internal RHEL 5-like kernel and to be >>> honest, I don't know what OpenIPMI driver is there :( I might try >>> vanilla one if it helps you debug things. >>> >>> When getting SDR (using IPMI_SYSTEM_INTERFACE_ADDR_TYPE), SDR record >>> tells me the owner of the sensor is 0xc2 (sensor->keys.owner_id), i.e. >>> if I understand it correctly, it points to itself. >>> >>> But ipmitool thinks the local IPMI address is 0x20 and tries to bridge >>> the sensor reading to IPMB addr 0xc2 (addr_type = IPMI_IPMB_ADDR_TYPE, >>> ipmi_ipmb_addr.slave_addr=0xc2) and gets error. >>> >>> Soooo, it seems I need to convince ipmitool that local address is not >>> 0x20 but 0xc2 using '-m' parameter and the target is 0xc2 too using >>> '-t'. This seems to work, but can it be automatized? Customers don't >>> like the '-m/t' voodoo, especially when ipmitool was working in the >>> old version. Ipmitool could look what's the real IPMB address instead >>> 0x20 at open(/dev/ipmi) time... What ioctl to use and how? I can hack >>> the ipmitool part then. >>> >>> Thanks in advance >>> >>> Jan >>> >> > ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Ipmitool-devel mailing list Ipmitool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
