IPMI detection false positive

[devicenull]

On CentOS, dmidecode -t 38 prints the following even if no IPMI controller is present:

 dmidecode -t 38
 # dmidecode 2.11
 SMBIOS 2.5 present.

 Handle 0x0028, DMI type 38, 18 bytes
 IPMI Device Information
    Interface Type: Unknown
    Specification Version: 1.0
    I2C Slave Address: 0x00
    NV Storage Device: Not Present
    Base Address: 0x0000000000000000 (Memory-mapped)
    Register Spacing: Successive Byte Boundaries

This causes a false positive, I would suggest the following instead:

%x{dmidecode -t 38 | grep "Interface Type" | grep -v "Unknown"}

[zoide]

Thanks for this. Unfortunatly your command would not work. What I am doing in the fact is to test whether dmidecode gives anything related to IPMI: "grep -q" being the relevant thing there.

I need to rewrite this fact a little bit, it seems

[devicenull]

Why wouldn't it work?

dmidecode -t 38 = Print information about an IPMI Device grep "Interface Type" = look for interface type line grep -v "Unknown" = filter out lines that don't contain a valid IPMI interface

The ultimate exit code here will be 0 if there's an 'Interface Type: (anything except unknown)' line, and 1 if there's either 'Interface Type: Unknown', or no 'Interface Type' line.

I'm using the modified line across my machines, and it appears to be working properly.

[rlex]

There is another case in which it can be false positive. I have old server with some Arima mobo, with sodimm-type slot for OPMA cards. Even if card is not present, it will show:

[root@tank ~]# dmidecode -t 38
# dmidecode 2.11
SMBIOS 2.4 present.

Handle 0x0022, DMI type 38, 18 bytes
IPMI Device Information
        Interface Type: KCS (Keyboard Control Style)
        Specification Version: 0.10
        I2C Slave Address: 0x0a
        NV Storage Device Address: 2
        Base Address: 0x0000000000000CA2 (I/O)
        Register Spacing: Successive Byte Boundaries

[rlex]

So i did a little digging around that problem I personally think that proper way of handling this will be checking for IPMI specification version. AFAIK there was no IPMI 1.0 hardware, only 1.5 and 2.0. But about 1.5... Ie on one of my servers:

lex@pve > sudo dmidecode -t 38
# dmidecode 2.9
SMBIOS 2.6 present.

Handle 0x0036, DMI type 38, 18 bytes
IPMI Device Information
    Interface Type: KCS (Keyboard Control Style)
    Specification Version: 2.0
    I2C Slave Address: 0x00
    NV Storage Device: Not Present
    Base Address: 0x0000000000000CA2 (I/O)
    Register Spacing: Successive Byte Boundaries

This is supermicro server with integrated IPMI. All correct.

However:

lex@azov > sudo dmidecode -t 38
# dmidecode 2.9
SMBIOS 2.4 present.

Handle 0x0050, DMI type 38, 18 bytes
IPMI Device Information
    Interface Type: KCS (Keyboard Control Style)
    Specification Version: 1.5
    I2C Slave Address: 0x00
    NV Storage Device: Not Present
    Base Address: 0x0000000000000000 (Memory-mapped)
    Register Spacing: Successive Byte Boundaries

lex@azov > sudo modprobe ipmi_si
FATAL: Error inserting ipmi_si (/lib/modules/2.6.32-5-amd64/kernel/drivers/char/ipmi/ipmi_si.ko): No such device

This is another supermicro server, with H8DGU motherboard. There is integrated ipmi 2.0 support in that mobo variations (-F and -LNF4), but in base version i have, ipmi is not integrated and can't be installed even with external card (maybe i'm wrong but i can't find any info about it). So this may be BIOS leftovers (since all that mobos almost same except few minor differences like SATA/SAS ports, IPMI and etc) which we can't detect in any way. So checking also for 1.5 specification can give false positive. And i does not see any ipmi 1.5 hardware around, even asked my friends, nope. Also v1.5 was released on 2001-03-01, and v2.0 on 2004-02-14. Honestly i think we can safely drop 1.5 support.

As for me, following line should not give any false positives:

%x{dmidecode -t 38 | grep "Specification Version: 2.0"}

Another possible solution can be checking is ipmi kernel module loaded successfully, but idea of loading unneeded modules on all servers is just wrong. But it works on my home NAS with that Areca mobo:

lex@tank > sudo modprobe ipmi_si
lex@tank > echo "$?"
1
lex@tank > lsmod | grep ipmi

(Also there may be another problem - you should specify offset for kernel module. But this is completely different problem) And one more another solution is to check for usb devices, but this is just stupid.

[ingardm]

Are we getting anywhere on this? I've got the following ouput from a Supermicro X8STi board.

dmidecode -t 38

dmidecode 2.9

SMBIOS 2.6 present.

Handle 0x003B, DMI type 38, 18 bytes IPMI Device Information Interface Type: Unknown Specification Version: 1.5 I2C Slave Address: 0x00 NV Storage Device: Not Present Base Address: 0x0000000000000000 (Memory-mapped) Register Spacing: Successive Byte Boundaries

[aseques]

On a supermicro blade (http://www.supermicro.com.tr/SBI-7125B-T1.cfm.htm) there is another weird result. It states version 1.0 but IPMI is only available on the blade itself, not the individual boards :( So in this case even the Version detection would fail ..

Handle 0x0030, DMI type 38, 18 bytes IPMI Device Information Interface Type: Unknown Specification Version: 1.0 I2C Slave Address: 0x00 NV Storage Device: Not Present Base Address: 0x0000000000000000 (Memory-mapped) Register Spacing: Successive Byte Boundaries