freeipmi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Freeipmi-devel] Re: [Freeipmi-users] querying sensors of Intel SE7210TP


From: Albert Chu
Subject: [Freeipmi-devel] Re: [Freeipmi-users] querying sensors of Intel SE7210TP1-E board fails with ipmi_sdr_cache_create: internal IPMI error
Date: Fri, 11 Feb 2011 17:44:26 -0800

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]