Public bug reported:
[Impact]
ipmi-locate will not detect and report BMCs in systems where the firmware
describes them only in an ACPI SPMI table. I surveyed several IPMI-capable
systems, and all but 1 describe their BMCs in SMBIOS, with a subset of those
also describing their BMC in ACPI as well. ipmi-locate works fine on those
systems because it successfully parses the SMBIOS (dmidecode) info. But, one
system - the HiSilicon D06 - only describes the BMC in ACPI. For this system,
ipmi-locate fails to find a BMC.
One way this surfaces to the user is with MAAS. MAAS uses ipmi-locate to
look for a BMC to determine which version of the IPMI protocol it
supports. The way the query works is that it checks for >= 2.0 support
and, if that fails, it assumes 1.5 support. Since ipmi-locate fails to
find *any* support, the fallback to 1.5 is triggered and MAAS tries to
talk to the system w/ IPMI LAN 1.5 protocol. This system actually
supports IPMI LAN 2.0 protocol, which is incompatible with 1.5 LAN
protocol, so MAAS is unable to power control the system. Even if you
manually enlist the node and tell it the node is IPMI 2.0, commissioning
will attempt to re-detect the BMC and reset it to 1.5.
[Test Case]
On a system where /sys/firmware/acpi/tables/SPMI* exists:
$ sudo ipmi-locate
At least one of the "[Probing KCS|SMIC|BT|SSIF] device using ACPI" tests
should not report "FAILED".
[Fix]
The following patch series from upstream git fixes the problem:
40ba578f8 Correct order of bytes in specification_revision field of ACPI SPMI
table
d92888128 Allow sysfs SPMI parsing on ARM platforms
158a901d7 Add support for parsing SPMI tables exposed via sysfs
184c74649 Split RSDT/XSDT parsing into new function
3c6fa7054 Don't try to separate the header from the ACPI table data
d8673cf67 Fix acpi spmi searching corner case
[Regression Risk]
While neither myself nor upstream are aware of a system where the existing
freeipmi ACPI/SPMI parsing code works - and works *correctly* - it is possible
that there is such a system. From my experimentation and reading of the code -
even if the existing code to extract an SPMI table from /dev/mem were to work,
the parsing of that table would be buggy and would not report correct
information (see commits 3c6fa7054 and 40ba578f8 for details). However - an
earlier version of this code did apparently work at some point on some system -
so it's possible that my parsing fixes would now break said system. Note that
for this to be an issue for the MAAS use-case, that system would also need to
*not* also describe the IPMI device in SMBIOS, which my survey of 4 systems
shows to be nearly always the case (except for the 1 case that triggered this
whole thing).
** Affects: freeipmi (Ubuntu)
Importance: High
Assignee: dann frazier (dannf)
Status: In Progress
** Affects: freeipmi (Ubuntu Bionic)
Importance: High
Assignee: dann frazier (dannf)
Status: In Progress
** Also affects: freeipmi (Ubuntu Bionic)
Importance: Undecided
Status: New
** Changed in: freeipmi (Ubuntu Bionic)
Status: New => In Progress
** Changed in: freeipmi (Ubuntu Bionic)
Importance: Undecided => High
** Changed in: freeipmi (Ubuntu Bionic)
Assignee: (unassigned) => dann frazier (dannf)
** Description changed:
[Impact]
ipmi-locate will not detect and report BMCs in systems where the firmware
describes them only in an ACPI SPMI table. I surveyed several IPMI-capable
systems, and all but 1 describe their BMCs in SMBIOS, with a subset of those
also describing their BMC in ACPI as well. ipmi-locate works fine on those
systems because it successfully parses the SMBIOS (dmidecode) info. But, one
system - the HiSilicon D06 - only describes the BMC in ACPI. For this system,
ipmi-locate fails to find a BMC.
One way this surfaces to the user is with MAAS. MAAS uses ipmi-locate to
look for a BMC to determine which version of the IPMI protocol it
supports. The way the query works is that it checks for >= 2.0 support
and, if that fails, it assumes 1.5 support. Since ipmi-locate fails to
find *any* support, the fallback to 1.5 is triggered and MAAS tries to
talk to the system w/ IPMI LAN 1.5 protocol. This system actually
supports IPMI LAN 2.0 protocol, which is incompatible with 1.5 LAN
protocol, so MAAS is unable to power control the system. Even if you
manually enlist the node and tell it the node is IPMI 2.0, commissioning
will attempt to re-detect the BMC and reset it to 1.5.
[Test Case]
$ sudo ipmi-locate
[Fix]
The following patch series from upstream git fixes the problem:
- 40ba578f8 (HEAD -> master, origin/master, origin/HEAD) Correct order of bytes
in specification_revision field of ACPI SPMI table
+ 40ba578f8 Correct order of bytes in specification_revision field of ACPI SPMI
table
d92888128 Allow sysfs SPMI parsing on ARM platforms
158a901d7 Add support for parsing SPMI tables exposed via sysfs
184c74649 Split RSDT/XSDT parsing into new function
3c6fa7054 Don't try to separate the header from the ACPI table data
d8673cf67 Fix acpi spmi searching corner case
[Regression Risk]
While neither myself nor upstream are aware of a system where the existing
freeipmi ACPI/SPMI parsing code works - and works *correctly* - it is possible
that there is such a system. From my experimentation and reading of the code -
even if the existing code to extract an SPMI table from /dev/mem were to work,
the parsing of that table would be buggy and would not report correct
information (see commits 3c6fa7054 and 40ba578f8 for details). However - an
earlier version of this code did apparently work at some point on some system -
so it's possible that my parsing fixes would now break said system. Note that
for this to be an issue for the MAAS use-case, that system would also need to
*not* also describe the IPMI device in SMBIOS, which my survey of 4 systems
shows to be nearly always the case (except for the 1 case that triggered this
whole thing).
** Description changed:
[Impact]
ipmi-locate will not detect and report BMCs in systems where the firmware
describes them only in an ACPI SPMI table. I surveyed several IPMI-capable
systems, and all but 1 describe their BMCs in SMBIOS, with a subset of those
also describing their BMC in ACPI as well. ipmi-locate works fine on those
systems because it successfully parses the SMBIOS (dmidecode) info. But, one
system - the HiSilicon D06 - only describes the BMC in ACPI. For this system,
ipmi-locate fails to find a BMC.
One way this surfaces to the user is with MAAS. MAAS uses ipmi-locate to
look for a BMC to determine which version of the IPMI protocol it
supports. The way the query works is that it checks for >= 2.0 support
and, if that fails, it assumes 1.5 support. Since ipmi-locate fails to
find *any* support, the fallback to 1.5 is triggered and MAAS tries to
talk to the system w/ IPMI LAN 1.5 protocol. This system actually
supports IPMI LAN 2.0 protocol, which is incompatible with 1.5 LAN
protocol, so MAAS is unable to power control the system. Even if you
manually enlist the node and tell it the node is IPMI 2.0, commissioning
will attempt to re-detect the BMC and reset it to 1.5.
[Test Case]
+ On a system where /sys/firmware/acpi/tables/SPMI* exists:
$ sudo ipmi-locate
+
+ At least one of the "[Probing KCS|SMIC|BT|SSIF] device using ACPI" tests
+ should not report "FAILED".
[Fix]
The following patch series from upstream git fixes the problem:
40ba578f8 Correct order of bytes in specification_revision field of ACPI SPMI
table
d92888128 Allow sysfs SPMI parsing on ARM platforms
158a901d7 Add support for parsing SPMI tables exposed via sysfs
184c74649 Split RSDT/XSDT parsing into new function
3c6fa7054 Don't try to separate the header from the ACPI table data
d8673cf67 Fix acpi spmi searching corner case
[Regression Risk]
While neither myself nor upstream are aware of a system where the existing
freeipmi ACPI/SPMI parsing code works - and works *correctly* - it is possible
that there is such a system. From my experimentation and reading of the code -
even if the existing code to extract an SPMI table from /dev/mem were to work,
the parsing of that table would be buggy and would not report correct
information (see commits 3c6fa7054 and 40ba578f8 for details). However - an
earlier version of this code did apparently work at some point on some system -
so it's possible that my parsing fixes would now break said system. Note that
for this to be an issue for the MAAS use-case, that system would also need to
*not* also describe the IPMI device in SMBIOS, which my survey of 4 systems
shows to be nearly always the case (except for the 1 case that triggered this
whole thing).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1784926
Title:
ipmi-locate fails to detect BMCs described by ACPI
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freeipmi/+bug/1784926/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
