group.of.nepali.translators team mailing list archive

[dann frazier <dann.frazier@xxxxxxxxxxxxx>]

** Also affects: freeipmi (Ubuntu Xenial)
   Importance: Undecided
       Status: New

** Changed in: freeipmi (Ubuntu Xenial)
       Status: New => In Progress

** Changed in: freeipmi (Ubuntu Xenial)
     Assignee: (unassigned) => dann frazier (dannf)

** Changed in: freeipmi (Ubuntu Xenial)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1784926

Title:
  ipmi-locate fails to detect BMCs described by ACPI

Status in freeipmi package in Ubuntu:
  Fix Released
Status in freeipmi source package in Xenial:
  In Progress
Status in freeipmi source package in Bionic:
  Fix Released

Bug 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]
  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).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freeipmi/+bug/1784926/+subscriptions