[Bug 1926299] Re: incorrect sensor is read on Lenovo server BMC

Fri May 21 04:28:22 UTC 2021

The attachment "groovy-1926299.debdiff" seems to be a debdiff.  The
ubuntu-sponsors team has been subscribed to the bug report so that they
can review and hopefully sponsor the debdiff.  If the attachment isn't a
patch, please remove the "patch" flag from the attachment, remove the
"patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe
the team.

[This is an automated message performed by a Launchpad user owned by
~brian-murray, for any issue please contact him.]

** Tags added: patch

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1926299

Title:
  incorrect sensor is read on Lenovo server BMC

Status in freeipmi package in Ubuntu:
  New
Status in freeipmi source package in Bionic:
  In Progress
Status in freeipmi source package in Focal:
  In Progress
Status in freeipmi source package in Groovy:
  In Progress
Status in freeipmi source package in Hirsute:
  In Progress
Status in freeipmi source package in Impish:
  New

Bug description:
  [impact]

  ipmi-sensors reads the wrong sensor on a Lenovo BMC (although the
  problem may happen on other BMCs as well)

  [test case]

  run ipmi-sensors over the network using ipmi 1.5 or 2 protocol, and
  check the sensor output. Specifically for this case, the server is a
  Lenovo SR665 with only 1 cpu socket populated, and dimms 1-16 are
  connected to cpu 1 while dimms 17-32 are connected to cpu2, so dimms
  17-32 should not return any values.

  $ ipmi-sensors -u $USERNAME -p $PASSWD -D LAN_2_0 -l USER -h $BMCADDR | grep DIMM | grep Temp
  110 | DIMM 1 Temp | Temperature | N/A | C | N/A
  113 | DIMM 2 Temp | Temperature | N/A | C | N/A
  116 | DIMM 3 Temp | Temperature | N/A | C | N/A
  119 | DIMM 4 Temp | Temperature | N/A | C | N/A
  122 | DIMM 5 Temp | Temperature | N/A | C | N/A
  125 | DIMM 6 Temp | Temperature | N/A | C | N/A
  128 | DIMM 7 Temp | Temperature | N/A | C | N/A
  131 | DIMM 8 Temp | Temperature | N/A | C | N/A
  134 | DIMM 9 Temp | Temperature | 52.00 | C | 'OK'
  137 | DIMM 10 Temp | Temperature | 42.00 | C | 'OK'
  140 | DIMM 11 Temp | Temperature | N/A | C | N/A
  143 | DIMM 12 Temp | Temperature | N/A | C | N/A
  146 | DIMM 13 Temp | Temperature | 27.00 | C | 'OK'
  149 | DIMM 14 Temp | Temperature | 26.00 | C | 'OK'
  152 | DIMM 15 Temp | Temperature | 24.00 | C | 'OK'
  155 | DIMM 16 Temp | Temperature | 24.00 | C | 'OK'
  158 | DIMM 17 Temp | Temperature | 218.00 | C | 'OK'
  161 | DIMM 18 Temp | Temperature | 212.00 | C | 'OK'
  165 | DIMM 19 Temp | Temperature | 212.00 | C | 'OK'
  173 | DIMM 20 Temp | Temperature | N/A | C | N/A
  176 | DIMM 21 Temp | Temperature | N/A | C | N/A
  179 | DIMM 22 Temp | Temperature | N/A | C | N/A
  182 | DIMM 23 Temp | Temperature | N/A | C | N/A
  185 | DIMM 24 Temp | Temperature | N/A | C | N/A
  188 | DIMM 25 Temp | Temperature | 0.00 | C | 'At or Below (<=) Lower Non-Critical Threshold'
  191 | DIMM 26 Temp | Temperature | 0.00 | C | 'At or Below (<=) Lower Non-Critical Threshold'
  194 | DIMM 27 Temp | Temperature | 0.00 | C | 'At or Below (<=) Lower Non-Critical Threshold'
  197 | DIMM 28 Temp | Temperature | 0.00 | C | 'At or Below (<=) Lower Non-Critical Threshold'
  200 | DIMM 29 Temp | Temperature | 0.00 | C | 'At or Below (<=) Lower Non-Critical Threshold'
  203 | DIMM 30 Temp | Temperature | 0.00 | C | 'At or Below (<=) Lower Non-Critical Threshold'
  206 | DIMM 31 Temp | Temperature | 0.00 | C | 'At or Below (<=) Lower Non-Critical Threshold'
  209 | DIMM 32 Temp | Temperature | N/A | C | N/A

  [regression potential]

  any regression would likely result in incorrect values shown for
  some/all sensor readings

  [scope]

  this is not fixed upstream, so it needed in all releases

  [other info]

  the problem is that this particular BMC has chosen to use a non-zero
  'LUN' number for these sensors; almost all BMCs use the standard LUN
  number 0, as the spec does state in section 19.3:

  "Unless otherwise specified, commands that are listed as mandatory
  must be accessed via LUN 00b"

  However the spec does allow for implementations to use alternate LUN
  numbers, specifically section 5.4 describes how the BMC would report
  the LUN number to the requesting software, and section 7.2 clarifies
  that while LUN 00b is reserved for devices beloning to the BMC itself
  and 10b is reserved for SMS messages, LUN numbers 01b and 11b are
  reserved for 'OEM' use. So it does appear valid for the BMC
  implementation to place sensor(s) under LUN 01b instead of the default
  00b.

  The cause of the invalid sensor readings in this particular case is
  because the BMC also defines sensors with the exact same sensor id
  number, but with LUN 00b. So when freeipmi attempts to read e.g. 'DIMM
  17 Temp' sensor, it actually reads the current value for a completely
  different sensor, which (in this case) isn't even a temperature
  sensor, resulting in invalid temperature reading shown for the sensor,
  instead of showing it as N/A (since the DIMM slot isn't populated).

  Note that ipmitool correctly uses the alternate LUN number so this bug
  does not exist with that tool, this affects only freeipmi tooling.

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