Has anyone had any success with the OpenIPMI kernel modules on dom0? I''ve been trying to get this to work on a IBM HS20 8843-25U blade running RHEL 4 Update 2 AS i386 (32-bit). I''ve tried compiling them into the xen0 kernel with the follow options in linux-2.6.12-xen0/.config: # # IPMI # CONFIG_IPMI_HANDLER=m # CONFIG_IPMI_PANIC_EVENT is not set CONFIG_IPMI_DEVICE_INTERFACE=m CONFIG_IPMI_SI=m CONFIG_IPMI_WATCHDOG=m CONFIG_IPMI_POWEROFF=m and doing modprobe ipmi_si which yields the following error message from dmesg: ipmi message handler version v33 IPMI System Interface driver version v33, KCS version v33, SMIC version v33, BT version v33 ipmi_si: Trying "kcs" at I/O port 0xca2 ipmi_si: Trying "smic" at I/O port 0xca9 ipmi_si: Trying "bt" at I/O port 0xe4 ipmi_si: Unable to find any System Interface(s) I was able to get ipmi_si to load properly on the default SMP kernel from RHEL 4, with the following messages from the kernel: ipmi message handler version 33.4 IPMI System Interface driver version 33.4, KCS version 33.4, SMIC version 33.4, BT version 33.4 ipmi_si: Found SMBIOS-specified state machine at I/O address 0xca8, slave address 0x20 IPMI kcs interface initialized ipmi device interface version 33.4 So, the BMC I have is on port 0xca8 instead of the default 0xca2. There''s code in linux-2.6.12-xen0/drivers/char/ipmi/ipmi_si_intf.c that is supposed to read the SMBIOS tables to find out from the type 38 structure what the actual BMC address is. This code uses isa_memcpy_fromio() to read memory from 0xf0000 to 0xfffff, and appears to read all 0''s, even though in user-space I can use mmap() on /dev/mem and find the SMBIOS entry point in that address space. If I specify the port that the BMC is on with modprobe ipmi_si ports=0xca8 I get the following message from the dom0 Linux kernel IPMI System Interface driver version v33, KCS version v33, SMIC version v33, BT version v33 ipmi_si: Trying "kcs" at I/O port 0xca8 ipmi_si: Unable to find any System Interface(s) so something else appears to be wrong here too, other than isa_memcpy_fromio()''s only reading 0''s from reserved memory blocks. The code to initialize a BMC starts in the init_one_smi() function in linux-2.6.12-xen0/drivers/char/ipmi/ipmi_si_intf.c . I think this code tries to send and write bytes from IO ports using inb() and outb() and don''t know whether these are known to work with Xen or not. Does anyone know anything about why this doesn''t work? Thanks in advance for your help. Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> So, the BMC I have is on port 0xca8 instead of the default > 0xca2. There''s code in > linux-2.6.12-xen0/drivers/char/ipmi/ipmi_si_intf.c that is > supposed to read the SMBIOS tables to find out from the type > 38 structure what the actual BMC address is. > This code uses isa_memcpy_fromio() to read memory from > 0xf0000 to 0xfffff, and appears to read all 0''s, even though > in user-space I can use mmap() on /dev/mem and find the > SMBIOS entry point in that address space.I presume you''re using xen-unstable? The dom0 kernel should have the bottom 1MB of machine memory mapper at PAGE_OFFSET (3GB) so isa_memcpy_fromio should work OK. Are you sure its not trying to read from a tale above 1MB? In which case you''ll need to ioremap it.> so something else appears to be wrong here too, other than > isa_memcpy_fromio()''s only reading 0''s from reserved memory > blocks. The code to initialize a BMC starts in the > init_one_smi() function in > linux-2.6.12-xen0/drivers/char/ipmi/ipmi_si_intf.c . > I think this code tries to send and write bytes from IO ports > using inb() and outb() and don''t know whether these are known > to work with Xen or not.inb/outb should work just fine, providing they are not to ports which Xen already owns e.g. COM1, RTC, PIC etc. Xen shouldn''t be interfering with the BMC. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> This may not be the best approach though, since the IPMI > drivers are not already patched for Xen and presumably > isa_memcpy_fromio() is a reasonable way to read memory in the > 0xf0000-0xfffff region. > > Why does isa_memcpy_fromio() not produce identical results > for the reserved 0xf0000-0xfffff section of memory in dom0 > and in a vanilla Linux 2.6.12.6 kernel?Try changing ISA_IO_BASE in include/asm-xen/asm-i386/io.h to #define __ISA_IO_base ((char __iomem *)(fix_to_virt(FIX_ISAMAP_BEGIN)) It''s arguable that we''d be better off maping the bottom 1MB of machine memory at PAGE_OFFSET rather than a fixmap as this would mean fewer Linux changes... Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I just went GNU hackers meetup yesterday in Milpitas. http://www.gnu.org/software/freeipmi/hackers-meet-2005.html Funny thing, is ... there were a bunch of High Performance Computing guys there, but no Xen hackers. If I ascertained correctly, OpenIPMI has problems. Have you tried FreeIPMI? I am not a kernel hacker, but FreeIPMI requires no kernel support. Albert Chu said they were about to add support in the Linux Kernel at Lawrence Livermore. I am about to fire up FreeIPMI. Is there some distinct advantage to OpenIPMI. I have only been using IPMI out-of- band up to this point to primarily do remote power. brian On Tue, 2005-11-08 at 18:11 -0500, Andrew D. Ball wrote:> Has anyone had any success with the OpenIPMI kernel modules on dom0? > I''ve been trying to get this to work on a IBM HS20 8843-25U blade > running RHEL 4 Update 2 AS i386 (32-bit). > > I''ve tried compiling them into the xen0 kernel with the follow options > in linux-2.6.12-xen0/.config: > > # > # IPMI > # > CONFIG_IPMI_HANDLER=m > # CONFIG_IPMI_PANIC_EVENT is not set > CONFIG_IPMI_DEVICE_INTERFACE=m > CONFIG_IPMI_SI=m > CONFIG_IPMI_WATCHDOG=m > CONFIG_IPMI_POWEROFF=m > > and doing > > modprobe ipmi_si > > which yields the following error message from dmesg: > > ipmi message handler version v33 > IPMI System Interface driver version v33, KCS version v33, SMIC version v33, BT > version v33 > ipmi_si: Trying "kcs" at I/O port 0xca2 > ipmi_si: Trying "smic" at I/O port 0xca9 > ipmi_si: Trying "bt" at I/O port 0xe4 > ipmi_si: Unable to find any System Interface(s) > > I was able to get ipmi_si to load properly on the default SMP kernel from RHEL 4, > with the following messages from the kernel: > > ipmi message handler version 33.4 > IPMI System Interface driver version 33.4, KCS version 33.4, SMIC version 33.4, > BT version 33.4 > ipmi_si: Found SMBIOS-specified state machine at I/O address 0xca8, slave > address 0x20 > IPMI kcs interface initialized > ipmi device interface version 33.4 > > So, the BMC I have is on port 0xca8 instead of the default 0xca2. There''s code in > linux-2.6.12-xen0/drivers/char/ipmi/ipmi_si_intf.c that is supposed to read the > SMBIOS tables to find out from the type 38 structure what the actual BMC address is. > This code uses isa_memcpy_fromio() to read memory from 0xf0000 to 0xfffff, and appears > to read all 0''s, even though in user-space I can use mmap() on /dev/mem and find the > SMBIOS entry point in that address space. > > If I specify the port that the BMC is on with > > modprobe ipmi_si ports=0xca8 > > I get the following message from the dom0 Linux kernel > > IPMI System Interface driver version v33, KCS version v33, SMIC version v33, BT > version v33 > ipmi_si: Trying "kcs" at I/O port 0xca8 > ipmi_si: Unable to find any System Interface(s) > > so something else appears to be wrong here too, other than isa_memcpy_fromio()''s only > reading 0''s from reserved memory blocks. The code to initialize a BMC starts in the > init_one_smi() function in linux-2.6.12-xen0/drivers/char/ipmi/ipmi_si_intf.c . > I think this code tries to send and write bytes from IO ports using inb() and outb() and > don''t know whether these are known to work with Xen or not. > > Does anyone know anything about why this doesn''t work? > > Thanks in advance for your help. > > Andrew > > > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel-- Brian Lavender <brian@xensource.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel