Thanks $ sudo /opt/freeipmi/sbin/ipmi-sensors -W assumeio ID | Name | Type | Reading | Units | Event 48 | ACPI State | System ACPI Power State | N/A | N/A | 'S0/G0' 96 | PCISLOT AREA TEM | Temperature | 31.00 | C | 'OK' 160 | SCSI-Gb AREA TEM | Temperature | 40.00 | C | 'OK' 224 | PwrConectr1 TEMP | Temperature | 34.00 | C | 'OK' 288 | PwrConectr2 TEMP | Temperature | 24.00 | C | 'OK' 352 | CPU0 VRM TEMP | Temperature | 31.00 | C | 'OK' 416 | CPU1 VRM TEMP | Temperature | 29.00 | C | 'OK' 480 | CPU0 TEMP | Temperature | 54.00 | C | 'OK' 544 | CPU1 TEMP | Temperature | 50.00 | C | 'OK' 608 | V5MBRUN | Voltage | N/A | N/A | 'Limit Not Exceeded' 656 | V2.5DUAL | Voltage | N/A | N/A | 'Limit Not Exceeded' 704 | V3.3DUAL | Voltage | N/A | N/A | 'Limit Not Exceeded' 752 | V5ALW | Voltage | N/A | N/A | 'Limit Not Exceeded' 800 | V5DUA | Voltage | N/A | N/A | 'Limit Not Exceeded' 848 | V3.3MBRUN | Voltage | N/A | N/A | 'Limit Not Exceeded' 896 | CPU0 Pres | Processor | N/A | N/A | 'Device Inserted/Device Present' 944 | CPU1 Pres | Processor | N/A | N/A | 'Device Inserted/Device Present' 992 | FAN1 Fault | Cooling Device | N/A | N/A | 'Performance Met' 1040 | FAN2 Fault | Cooling Device | N/A | N/A | 'Performance Met' 1088 | FAN3 Fault | Cooling Device | N/A | N/A | 'Performance Met' 1136 | FAN4 Fault | Cooling Device | N/A | N/A | 'Performance Met' 1184 | FAN5 Fault | Cooling Device | N/A | N/A | 'Performance Met' 1232 | Pwr Sply1Pres | Power Supply | N/A | N/A | 'Device Inserted/Device Present' 1280 | Pwr Sply1Fault | Power Supply | N/A | N/A | 'State Deasserted' 1328 | Therm-Trip | Processor | N/A | N/A | 'State Deasserted'
--- On Wed, 9/15/10, Albert Chu <[email protected]> wrote: > From: Albert Chu <[email protected]> > Subject: Re: [Freeipmi-devel] ipmi_ctx_find_inband: device already open > To: "Kenneth Stailey" <[email protected]> > Cc: "[email protected]" <[email protected]> > Date: Wednesday, September 15, 2010, 6:24 PM > Hey Kenneth, > > I got a beta.tar.gz up with my workaround. The > workaround is "-W > assumeio", which you can specify to ipmi-sensors and most > of the tools. > It'll do pretty much what is expected, which is to assume > I/O w/ the > base address even when it doesn't say so. When you > compile, can you > please try w/ --enable-debug and --enable-trace, so we can > make sure > that it's working as expected. > > The tar.gz can be downloaded: > > http://ftp.gluster.com/pub/freeipmi/qa-release/freeipmi-0.8.10.beta0.tar.gz > > Thanks, > > Al > > On Wed, 2010-09-15 at 10:02 -0700, Albert Chu wrote: > > Hey Kenneth, > > > > Thanks for the info. I'll try and put a > workaround into FreeIPMI to > > deal with this. I decided to look at the IPMI > kernel driver to see what > > they are doing internally and found this: > > > > > /* Note that technically, the lower bit of > the base > > > * address should be 1 if the address is I/O and 0 if > > > * the address is in memory. So many systems get > that > > > * wrong (and all that I have seen are I/O) so we > just > > > * ignore that bit and assume I/O. Systems that > use > > > * memory should use the newer spec, anyway. */ > > > dmi->base_addr = base_addr & > 0xfffe; > > > dmi->addr_space = IPMI_IO_ADDR_SPACE; > > > dmi->offset = 1; > > > > so they are just ignoring that bit and using I/O > anyways. So I bet this > > is what is going on in your motherboard w/ the IPMI > kernel driver. > > > > Al > > > > On Wed, 2010-09-15 at 06:20 -0700, Kenneth Stailey > wrote: > > > ipmi-sensors -D KCS --disable-auto-probe > --driver-address=0xCA2 > > > --register-spacing=1 > > > > > > does work > > > > > > --- On Tue, 9/14/10, Albert Chu <[email protected]> > wrote: > > > > > > > From: Albert Chu <[email protected]> > > > > Subject: Re: [Freeipmi-devel] > ipmi_ctx_find_inband: device already open > > > > To: "Kenneth Stailey" <[email protected]> > > > > Cc: "[email protected]" > <[email protected]> > > > > Date: Tuesday, September 14, 2010, 7:23 PM > > > > Hey Kenneth, > > > > > > > > I now see the full "path" of what's going > on. The key > > > > is the > > > > 'IPMI_ADDRESS_SPACE_ID_SYSTEM_IO' bit, that > indicates that > > > > system IO > > > > isn't supported w/ KCS. > > > > > > > > However, with the info from the ipmi-locate > below, it > > > > strongly suggests > > > > that KCS is supported, but that maybe that > bit was set > > > > wrong. For fun, > > > > could you give the following a try? > > > > > > > > ipmi-sensors -D KCS --disable-auto-probe > > > > --driver-address=0xCA2 > > > > --register-spacing=1 > > > > > > > > and see if that works? If it does, > then we atleast > > > > have something we > > > > can point to HP and say there's an issue. > > > > > > > > Thanks, > > > > Al > > > > > > > > On Tue, 2010-09-14 at 15:28 -0700, Kenneth > Stailey wrote: > > > > > > > > > > --- On Tue, 9/14/10, Albert Chu <[email protected]> > > > > wrote: > > > > > > > > > > > I'm beginning to wonder if your > motherboard > > > > simply has an > > > > > > interface that > > > > > > is supported by the IPMI kernel > driver but not > > > > by > > > > > > FreeIPMI's default > > > > > > libraries. Could you run > ipmi-locate real > > > > quick to > > > > > > see? > > > > > > > > > > Using unpatched ipmi-locate: > > > > > > > > > > k...@niobium:~/src/freeipmi-0.8.9$ sudo > rmmod ipmi_si > > > > ipmi_devintf ipmi_msghandler > > > > > > > > > > k...@niobium:~/src/freeipmi-0.8.9$ type > ipmi-locate > > > > > ipmi-locate is /usr/sbin/ipmi-locate > > > > > > > > > > k...@niobium:~/src/freeipmi-0.8.9$ > ipmi-locate > > > > --version > > > > > ipmi-locate - 0.8.9 > > > > > Copyright (C) 2003-2010 FreeIPMI Core > Team > > > > > This program is free software; you may > redistribute it > > > > under the terms of > > > > > the GNU General Public License. > This program has > > > > absolutely no warranty. > > > > > > > > > > k...@niobium:~/src/freeipmi-0.8.9$ sudo > ipmi-locate > > > > > Probing KCS device using DMIDECODE... > done > > > > > IPMI Version: 1.5 > > > > > IPMI locate driver: DMIDECODE > > > > > IPMI interface: KCS > > > > > BMC driver device: > > > > > BMC memory base address: 0xCA2 > > > > > Register spacing: 1 > > > > > > > > > > Probing SMIC device using DMIDECODE... > FAILED > > > > > > > > > > Probing BT device using DMIDECODE... > FAILED > > > > > > > > > > Probing SSIF device using DMIDECODE... > FAILED > > > > > > > > > > Probing KCS device using SMBIOS... > done > > > > > IPMI Version: 1.5 > > > > > IPMI locate driver: SMBIOS > > > > > IPMI interface: KCS > > > > > BMC driver device: > > > > > BMC memory base address: 0xCA3 > > > > > Register spacing: 1 > > > > > > > > > > Probing SMIC device using SMBIOS... > FAILED > > > > > > > > > > Probing BT device using SMBIOS... > FAILED > > > > > > > > > > Probing SSIF device using SMBIOS... > FAILED > > > > > > > > > > Probing KCS device using ACPI... > FAILED > > > > > > > > > > Probing SMIC device using ACPI... > FAILED > > > > > > > > > > Probing BT device using ACPI... FAILED > > > > > > > > > > Probing SSIF device using ACPI... > FAILED > > > > > > > > > > Probing KCS device using PCI... FAILED > > > > > > > > > > Probing SMIC device using PCI... > FAILED > > > > > > > > > > Probing BT device using PCI... FAILED > > > > > > > > > > Probing SSIF device using PCI... > FAILED > > > > > > > > > > KCS device default values: > > > > > IPMI Version: 1.5 > > > > > IPMI locate driver: DEFAULT > > > > > IPMI interface: KCS > > > > > BMC driver device: > > > > > BMC I/O base address: 0xCA2 > > > > > Register spacing: 1 > > > > > > > > > > SMIC device default values: > > > > > IPMI Version: 1.5 > > > > > IPMI locate driver: DEFAULT > > > > > IPMI interface: SMIC > > > > > BMC driver device: > > > > > BMC I/O base address: 0xCA9 > > > > > Register spacing: 1 > > > > > > > > > > BT device default values: > > > > > SSIF device default values: > > > > > IPMI Version: 1.5 > > > > > IPMI locate driver: DEFAULT > > > > > IPMI interface: SSIF > > > > > BMC driver device: /dev/i2c-0 > > > > > BMC SMBUS slave address: 0x42 > > > > > Register spacing: 1 > > > > -- > > > > Albert Chu > > > > [email protected] > > > > Computer Scientist > > > > High Performance Systems Division > > > > Lawrence Livermore National Laboratory > > > > > > > > > -- > 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
