gbmc-release-23.18.x: nvmesensor: hack to avoid huge amount of VF
This patch only include one line code change. `index++;` -> `break;`
nvmesensor created too much VF(secondary) controllers DBus objects
even when most of those VF controllers are offline state. The
creation of those DBus objects will make xyz.openbmc_project.ObjectMapper
slow or even timeout when response to other component of BMC.
This is a release branch only patch to meet the urgent timeline.
In master branch, we will solve this issue more gracefully by
moderate code change.
Tested:
Power cycle and check host bootnum passed 20 loops:
https://paste.googleplex.com/4562061991346176?raw
OOB test without VF controllers:
https://fusion2.corp.google.com/ci/guitar/workflows/%2F%2Fplatforms%2Fgbmc%2Fmtest%2Fintegration_test:izumi_ironfist_nightly_regression/activity/f88f8744-6e28-300b-88bb-c5ad3b607fb7:0/phases
(The failure tests already failed on `23.18.48.0`)
Google-Bug-Id: 301462811
Google-Bug-Id: 298022427
Change-Id: I46fe34c703ca739c0dac668ccf70ec0b372a0664
Signed-off-by: Jinliang Wang <jinliangw@google.com>
diff --git a/recipes-phosphor/sensors/dbus-sensors/0001-nvmesensor-hack-to-avoid-huge-ammount-of-VF.patch b/recipes-phosphor/sensors/dbus-sensors/0001-nvmesensor-hack-to-avoid-huge-ammount-of-VF.patch
new file mode 100644
index 0000000..8806335
--- /dev/null
+++ b/recipes-phosphor/sensors/dbus-sensors/0001-nvmesensor-hack-to-avoid-huge-ammount-of-VF.patch
@@ -0,0 +1,53 @@
+From 5fff638d4b73aa025010cc9a2edde9f0cc865f25 Mon Sep 17 00:00:00 2001
+From: Jinliang Wang <jinliangw@google.com>
+Date: Thu, 21 Sep 2023 11:29:35 -0700
+Subject: [PATCH] nvmesensor: hack to avoid huge ammount of VF
+
+nvmesensor created too much VF(secondary) controllers DBus objects
+even when most of those VF controllers are offline state. The
+creation of those DBus objects will make xyz.openbmc_project.ObjectMapper
+slow or even timeout when response to other component of BMC.
+
+This is a release branch only patch to meet the urgent timeline.
+In master branch, we will solve this issue more gracefully by
+moderate code change.
+
+Tested:
+On 12 SDD machine:
+Before the fix:
+ busctl tree | grep -i ironfist | grep -i controller | wc -l
+ 3210
+After the fix:
+ busctl tree | grep -i controller | grep -i ironfist | wc -l
+ 126
+
+Google-Bug-Id:301462811
+Change-Id: I38e49b534d13caea6c4ddaa3a9660bf25f588c31
+Signed-off-by: Jinliang Wang <jinliangw@google.com>
+---
+ src/NVMeSubsys.cpp | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+diff --git a/src/NVMeSubsys.cpp b/src/NVMeSubsys.cpp
+index 32f0304..cd7da38 100644
+--- a/src/NVMeSubsys.cpp
++++ b/src/NVMeSubsys.cpp
+@@ -221,8 +221,13 @@ void NVMeSubsystem::markFunctional(bool toggle)
+ << std::to_string(*index)
+ << ", reason: " << e.what() << std::endl;
+ }
+-
+- index++;
++ /*
++ Quik workaround for b/301462811, here we rely on a
++ weak and immature assumption that: there is only
++ one primary controller and its controller ID is the
++ first one returned by miScanCtrl
++ */
++ break;
+ }
+ // self->createStorageAssociation();
+
+--
+2.42.0.515.g380fc7ccd1-goog
+
diff --git a/recipes-phosphor/sensors/dbus-sensors_%.bbappend b/recipes-phosphor/sensors/dbus-sensors_%.bbappend
index cae49aa..330197c 100644
--- a/recipes-phosphor/sensors/dbus-sensors_%.bbappend
+++ b/recipes-phosphor/sensors/dbus-sensors_%.bbappend
@@ -80,6 +80,7 @@
file://0017-nvmesensor-fix-compile-issue-after-mearging-cleaning.patch \
file://0018-nvmesensor-increase-timeout-for-sanitize-and-namesap.patch \
file://0019-nvmesensor-print-makeLibNVMeError-for-debug.patch \
+ file://0001-nvmesensor-hack-to-avoid-huge-ammount-of-VF.patch \
"
PACKAGECONFIG[nvmesensor] = "-Dnvme=enabled, -Dnvme=disabled, libnvme libnvme-vu"
SYSTEMD_SERVICE:${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'nvmesensor', \
