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 [email protected] Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/freeipmi-devel
