[Freeipmi-devel] Re: [Freeipmi-users] querying sensors of Intel SE7210TP1-E board fails with ipmi_sdr_cache_create: internal IPMI error

[Albert Chu]

Hey Christian,

Could you run

ipmiutil sel -v -x

the -x is to get some debug info, the "sel -v" is to just get a shorter
output (don't need all the sensor debug info, just how ipmiutil is
getting to the data :-).

One other random thought.  I think it's possible that your motherboard
supports the KCS driver, it's just not "advertised".  Perhaps you can
give

bmc-info -D kcs --disable-auto-probe --driver-address=0x84
--register-spacing=1 a shot?

Al

On Sat, 2011-02-12 at 05:32 -0800, Christian Ruppert wrote:
> Hi Albert,
> 
> I don't get any data with the other commands at all.
> 
> # ipmi-chassis --get-chassis-status
> ipmi-ssif-driver.c: 269: _ipmi_i2c_smbus_access: errno '' (6)
> ipmi-ssif-driver-api.c: 266: _ssif_cmd_read: error 'internal system
> error' (12)
> ipmi-chassis-cmds-api.c: 146: ipmi_cmd_get_chassis_status: error
> 'internal system error' (31)
> ipmi_cmd_get_chassis_status: internal system error
> 
> # bmc-device --get-ssif-interface-capabilities
> ipmi-ssif-driver.c: 269: _ipmi_i2c_smbus_access: errno '' (6)
> ipmi-ssif-driver-api.c: 266: _ssif_cmd_read: error 'internal system
> error' (12)
> ipmi-messaging-support-cmds-api.c: 693:
> ipmi_cmd_get_system_interface_capabilities_ssif: error 'internal system
> error' (31)
> ipmi_cmd_get_system_interface_capabilities_ssif: internal system error
> 
> and so on...
> 
> Somebody told me about ipmiutil, it seems to work.
> 
> # ipmiutil sensor -s
> ipmiutil ver 2.67
> isensor: version 2.67
> -- BMC version 2.40, IPMI version 1.5
> Full sensor   [000a]| snum 0b | Baseboard 1.5V   | OK   | 1.52 Volts
> GetSensorReading error cb Requested sensor, data, or record not present
> Full sensor   [000b]| snum 0c | Baseboard 3.3V   | OK   | 0.00 Volts
> GetSensorReading error cb Requested sensor, data, or record not present
> Full sensor   [000c]| snum 0d | Baseboard 5.0V   | OK   | 0.00 Volts
> GetSensorReading error cb Requested sensor, data, or record not present
> Full sensor   [000d]| snum 0e | Baseboard 12V    | OK   | 0.00 Volts
> Full sensor   [000e]| snum 10 | Processor Vccp   | OK   | 1.35 Volts
> Full sensor   [000f]| snum 11 | Baseboard Temp   | OK   | 34.00 degrees C
> ...
> 
> I would be glad if we could fix that in FreeIPMI too :)
> I could give you access to the box with that SSIF device, if you want :)
> 
> On 02/12/2011 02:44 AM, Albert Chu wrote:
> > Hey Christian,
> > 
> >> No luck with 0x84 but 0x42 looks better, I hope it helps.
> > 
> > That's good.  I guess the random luck of the order I probe devices isn't
> > good for your motherboard.  I'd like to flip the probing order around
> > for you, but I'm sort of afraid it'll mess up another persons system.
> > Let me see if I can come up w/ something more creative to deal with
> > this.
> > 
> > But atleast in the short term you have something that would work for
> > you.  If you configure /etc/freeipmi/freeipmi.conf, you can set the
> > below as defaults so that you don't have to type them everytime.
> > 
> >> ipmi-ssif-driver.c: 269: _ipmi_i2c_smbus_access: errno '' (6)
> > 
> > This is really odd, errno 6 = ENXIO which means "no such device or
> > address", but clearly it just worked w/ the previous packet.  I wonder
> > if the ENXIO refers to something deeper inside IPMI, not something
> > related to the actual device.
> > 
> > Could you try other random IPMI commands, ipmi-chassis, bmc-device,
> > ipmi-sensors, ipmi-sel, and see what they output.  Perhaps I need to
> > handle ENXIO a special way, maybe it means something.
> > 
> > Al
> > 
> > On Fri, 2011-02-11 at 16:05 -0800, Christian Ruppert wrote:
> >> No luck with 0x84 but 0x43 looks better, I hope it helps.
> >>
> >> # bmc-info -D ssif --disable-auto-probe --driver-address=0x84
> >> --driver-device=/dev/i2c-0 --register-spacing=1
> >> ipmi-ssif-driver.c: 685: ipmi_ssif_ctx_io_init: errno '' (22)
> >> ipmi-api.c: 1012: ipmi_ctx_open_inband: error 'internal error' (13)
> >> ipmi-api.c: 2029: ipmi_ctx_close: error 'device not open' (16)
> >> ipmi_ctx_open_inband: internal error
> >>
> >>
> >> bmc-info -D ssif --disable-auto-probe --driver-address=0x42
> >> --driver-device=/dev/i2c-0 --register-spacing=1
> >>
> >> Device ID             : 32
> >> Device Revision       : 1
> >> Device SDRs           : supported
> >> Firmware Revision     : 2.40
> >> Device Available      : yes (normal operation)
> >> IPMI Version          : 1.5
> >> Sensor Device         : supported
> >> SDR Repository Device : supported
> >> SEL Device            : supported
> >> FRU Inventory Device  : supported
> >> IPMB Event Receiver   : supported
> >> IPMB Event Generator  : unsupported
> >> Bridge                : unsupported
> >> Chassis Device        : supported
> >> Manufacturer ID       : National Semiconductor (802)
> >> Product ID            : 17169
> >>
> >> ipmi-ssif-driver.c: 269: _ipmi_i2c_smbus_access: errno '' (6)
> >> ipmi-ssif-driver-api.c: 266: _ssif_cmd_read: error 'internal system
> >> error' (12)
> >> ipmi-device-global-cmds-api.c: 422: ipmi_cmd_get_device_guid: error
> >> 'internal system error' (31)
> >> ipmi_cmd_get_device_guid: internal system error
> >>
> >>
> >> On 02/09/2011 10:56 PM, Albert Chu wrote:
> >>> Hey Christian,
> >>>
> >>> Thanks for the traces.  I noticed something peculiar in the ipmi-locate
> >>> output.
> >>>
> >>> Probing SSIF device using DMIDECODE... done
> >>> IPMI Version: 1.5
> >>> IPMI locate driver: DMIDECODE
> >>> IPMI interface: SSIF
> >>> BMC driver device: /dev/i2c-0
> >>> BMC SMBUS slave address: 0x42
> >>> Register spacing: 1
> >>>
> >>> Probing SSIF device using SMBIOS... done
> >>> IPMI Version: 1.5
> >>> IPMI locate driver: SMBIOS
> >>> IPMI interface: SSIF
> >>> BMC driver device: /dev/i2c-0
> >>> BMC SMBUS slave address: 0x84
> >>> Register spacing: 1
> >>>
> >>> The probing finds 2 different slave addresses.  I'm not sure why.
> >>> Perhaps you could try setting the driver values manually to see if it
> >>> changes things??
> >>>
> >>> bmc-info -D ssif --disable-auto-probe --driver-address=0x84
> >>> --driver-device=/dev/i2c-0 --register-spacing=1
> >>>
> >>> and also try 0x42 for the driver-address.
> >>>
> >>> Assuming the FreeIPMI ssif driver doesn't have bugs (I don't have a
> >>> machine that uses SSIF, so I've never tried it, I can only assume the
> >>> original writers did it without bugs), it's possible the OpenIPMI kernel
> >>> driver probes for addresses in an alternate order to the way FreeIPMI
> >>> does, and by happen chance gets the right values.  That might explain
> >>> things.
> >>>
> >>> Al
> >>>
> >>> On Wed, 2011-02-09 at 10:14 -0800, Christian Ruppert wrote:
> >>>> Hey guys,
> >>>>
> >>>> take a look at the attachments for "impi-locate" and "bmc-info --debug"
> >>>> with debug/trace enabled.
> >>>>
> >>>> The kernel driver is only available through OpenIPMI and the patches are
> >>>> only available up to kernel 2.6.35. I didn't get to the OpenIPMI kernel
> >>>> drivers yet to port them to .36 and above. So I'd like to use FreeIPMI
> >>>> instead if it works without any kernel drivers at all.
> >>>>
> >>
> 
> 
-- 
Albert Chu
address@hidden
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory