| 2018-08-01 18:44:18 |
dann frazier |
bug |
|
|
added bug |
| 2018-08-01 18:44:25 |
dann frazier |
nominated for series |
|
Ubuntu Bionic |
|
| 2018-08-01 18:44:25 |
dann frazier |
bug task added |
|
freeipmi (Ubuntu Bionic) |
|
| 2018-08-01 18:44:34 |
dann frazier |
freeipmi (Ubuntu Bionic): status |
New |
In Progress |
|
| 2018-08-01 18:44:35 |
dann frazier |
freeipmi (Ubuntu Bionic): importance |
Undecided |
High |
|
| 2018-08-01 18:44:38 |
dann frazier |
freeipmi (Ubuntu Bionic): assignee |
|
dann frazier (dannf) |
|
| 2018-08-01 18:45:38 |
dann frazier |
description |
[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
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). |
[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 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). |
|
| 2018-08-01 18:48:03 |
dann frazier |
description |
[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 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). |
[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). |
|
| 2018-08-09 16:43:30 |
Launchpad Janitor |
freeipmi (Ubuntu): status |
In Progress |
Fix Released |
|
| 2018-08-09 20:26:23 |
Brian Murray |
freeipmi (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2018-08-09 20:26:25 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2018-08-09 20:26:27 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2018-08-09 20:26:31 |
Brian Murray |
tags |
|
verification-needed verification-needed-bionic |
|
| 2018-08-09 22:09:05 |
dann frazier |
tags |
verification-needed verification-needed-bionic |
verification-done verification-done-bionic |
|
| 2018-08-20 11:30:11 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2018-08-20 11:30:09 |
Launchpad Janitor |
freeipmi (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2019-02-14 21:09:53 |
dann frazier |
nominated for series |
|
Ubuntu Xenial |
|
| 2019-02-14 21:09:53 |
dann frazier |
bug task added |
|
freeipmi (Ubuntu Xenial) |
|
| 2019-02-14 21:10:03 |
dann frazier |
freeipmi (Ubuntu Xenial): status |
New |
In Progress |
|
| 2019-02-14 21:10:06 |
dann frazier |
freeipmi (Ubuntu Xenial): assignee |
|
dann frazier (dannf) |
|
| 2019-02-14 21:10:08 |
dann frazier |
freeipmi (Ubuntu Xenial): importance |
Undecided |
High |
|
| 2019-03-08 11:21:02 |
Timo Aaltonen |
freeipmi (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2019-03-08 11:21:05 |
Timo Aaltonen |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2019-03-08 11:21:10 |
Timo Aaltonen |
tags |
verification-done verification-done-bionic |
verification-done-bionic verification-needed verification-needed-xenial |
|
| 2019-03-08 15:04:34 |
dann frazier |
tags |
verification-done-bionic verification-needed verification-needed-xenial |
verification-done verification-done-bionic verification-done-xenial |
|
| 2019-03-18 10:39:33 |
Launchpad Janitor |
freeipmi (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2019-06-14 19:50:54 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/freeipmi/+git/freeipmi/+merge/368338 |
|
| 2019-06-14 20:10:56 |
Launchpad Janitor |
merge proposal unlinked |
https://code.launchpad.net/~ahasenack/ubuntu/+source/freeipmi/+git/freeipmi/+merge/368338 |
|
|
