freeipmi-devel
[Top][All Lists]
Advanced

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

Re: [Freeipmi-devel] ipmi_ctx_find_inband: device already open


From: Albert Chu
Subject: Re: [Freeipmi-devel] ipmi_ctx_find_inband: device already open
Date: Wed, 15 Sep 2010 15:24:21 -0700

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 <address@hidden> wrote:
> > 
> > > From: Albert Chu <address@hidden>
> > > Subject: Re: [Freeipmi-devel] ipmi_ctx_find_inband: device already open
> > > To: "Kenneth Stailey" <address@hidden>
> > > Cc: "address@hidden" <address@hidden>
> > > 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 <address@hidden>
> > > 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:
> > > > 
> > > > address@hidden:~/src/freeipmi-0.8.9$ sudo rmmod ipmi_si
> > > ipmi_devintf ipmi_msghandler
> > > > 
> > > > address@hidden:~/src/freeipmi-0.8.9$ type ipmi-locate
> > > > ipmi-locate is /usr/sbin/ipmi-locate
> > > > 
> > > > address@hidden:~/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.
> > > > 
> > > > address@hidden:~/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
> > > address@hidden
> > > Computer Scientist
> > > High Performance Systems Division
> > > Lawrence Livermore National Laboratory
> > > 
> > > 
-- 
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]