"fef66a951fe6fe283515480b2c493dfdc2275a95" (history) in projects: openbmc

Searched hist:fef66a951fe6fe283515480b2c493dfdc2275a95 (Results 1 – 10 of 10) sorted by relevance

/openbmc/phosphor-debug-collector/
H A D	elog_watch.hpp	diff fef66a951fe6fe283515480b2c493dfdc2275a95 Sun Sep 06 13:10:59 CDT 2020 Dhruvaraj Subhashchandran <dhruvaraj@in.ibm.com> Create dump manager for each dump type. Currently all types of dumps exist in the same path and under the single dump manager. When there are multiple dumps to be created separate path is needed for creating and managing the dump. this commit is splitting the dump manager into multiple objects without adding any new functionality. There will be only one dump manager process but it will contain seperate dump manager objects for system and BMC dumps as per current scope. Tested the existing dump functions with the build - created bmc dump - created system dump using notify - deleted dump entry - offloaded bmc dump Signed-off-by: Dhruvaraj Subhashchandran <dhruvaraj@in.ibm.com> Change-Id: Id4806660be1f1ba0b3cb6f840ae185a967f05a83
H A D	dump_manager.cpp	diff fef66a951fe6fe283515480b2c493dfdc2275a95 Sun Sep 06 13:10:59 CDT 2020 Dhruvaraj Subhashchandran <dhruvaraj@in.ibm.com> Create dump manager for each dump type. Currently all types of dumps exist in the same path and under the single dump manager. When there are multiple dumps to be created separate path is needed for creating and managing the dump. this commit is splitting the dump manager into multiple objects without adding any new functionality. There will be only one dump manager process but it will contain seperate dump manager objects for system and BMC dumps as per current scope. Tested the existing dump functions with the build - created bmc dump - created system dump using notify - deleted dump entry - offloaded bmc dump Signed-off-by: Dhruvaraj Subhashchandran <dhruvaraj@in.ibm.com> Change-Id: Id4806660be1f1ba0b3cb6f840ae185a967f05a83
H A D	dump_manager.hpp	diff fef66a951fe6fe283515480b2c493dfdc2275a95 Sun Sep 06 13:10:59 CDT 2020 Dhruvaraj Subhashchandran <dhruvaraj@in.ibm.com> Create dump manager for each dump type. Currently all types of dumps exist in the same path and under the single dump manager. When there are multiple dumps to be created separate path is needed for creating and managing the dump. this commit is splitting the dump manager into multiple objects without adding any new functionality. There will be only one dump manager process but it will contain seperate dump manager objects for system and BMC dumps as per current scope. Tested the existing dump functions with the build - created bmc dump - created system dump using notify - deleted dump entry - offloaded bmc dump Signed-off-by: Dhruvaraj Subhashchandran <dhruvaraj@in.ibm.com> Change-Id: Id4806660be1f1ba0b3cb6f840ae185a967f05a83
H A D	dump_manager_bmc.hpp	fef66a951fe6fe283515480b2c493dfdc2275a95 Sun Sep 06 13:10:59 CDT 2020 Dhruvaraj Subhashchandran <dhruvaraj@in.ibm.com> Create dump manager for each dump type. Currently all types of dumps exist in the same path and under the single dump manager. When there are multiple dumps to be created separate path is needed for creating and managing the dump. this commit is splitting the dump manager into multiple objects without adding any new functionality. There will be only one dump manager process but it will contain seperate dump manager objects for system and BMC dumps as per current scope. Tested the existing dump functions with the build - created bmc dump - created system dump using notify - deleted dump entry - offloaded bmc dump Signed-off-by: Dhruvaraj Subhashchandran <dhruvaraj@in.ibm.com> Change-Id: Id4806660be1f1ba0b3cb6f840ae185a967f05a83
H A D	dump_manager_main.cpp	diff fef66a951fe6fe283515480b2c493dfdc2275a95 Sun Sep 06 13:10:59 CDT 2020 Dhruvaraj Subhashchandran <dhruvaraj@in.ibm.com> Create dump manager for each dump type. Currently all types of dumps exist in the same path and under the single dump manager. When there are multiple dumps to be created separate path is needed for creating and managing the dump. this commit is splitting the dump manager into multiple objects without adding any new functionality. There will be only one dump manager process but it will contain seperate dump manager objects for system and BMC dumps as per current scope. Tested the existing dump functions with the build - created bmc dump - created system dump using notify - deleted dump entry - offloaded bmc dump Signed-off-by: Dhruvaraj Subhashchandran <dhruvaraj@in.ibm.com> Change-Id: Id4806660be1f1ba0b3cb6f840ae185a967f05a83
H A D	elog_watch.cpp	diff fef66a951fe6fe283515480b2c493dfdc2275a95 Sun Sep 06 13:10:59 CDT 2020 Dhruvaraj Subhashchandran <dhruvaraj@in.ibm.com> Create dump manager for each dump type. Currently all types of dumps exist in the same path and under the single dump manager. When there are multiple dumps to be created separate path is needed for creating and managing the dump. this commit is splitting the dump manager into multiple objects without adding any new functionality. There will be only one dump manager process but it will contain seperate dump manager objects for system and BMC dumps as per current scope. Tested the existing dump functions with the build - created bmc dump - created system dump using notify - deleted dump entry - offloaded bmc dump Signed-off-by: Dhruvaraj Subhashchandran <dhruvaraj@in.ibm.com> Change-Id: Id4806660be1f1ba0b3cb6f840ae185a967f05a83
H A D	dump_manager_bmc.cpp	fef66a951fe6fe283515480b2c493dfdc2275a95 Sun Sep 06 13:10:59 CDT 2020 Dhruvaraj Subhashchandran <dhruvaraj@in.ibm.com> Create dump manager for each dump type. Currently all types of dumps exist in the same path and under the single dump manager. When there are multiple dumps to be created separate path is needed for creating and managing the dump. this commit is splitting the dump manager into multiple objects without adding any new functionality. There will be only one dump manager process but it will contain seperate dump manager objects for system and BMC dumps as per current scope. Tested the existing dump functions with the build - created bmc dump - created system dump using notify - deleted dump entry - offloaded bmc dump Signed-off-by: Dhruvaraj Subhashchandran <dhruvaraj@in.ibm.com> Change-Id: Id4806660be1f1ba0b3cb6f840ae185a967f05a83
H A D	meson.build	diff fef66a951fe6fe283515480b2c493dfdc2275a95 Sun Sep 06 13:10:59 CDT 2020 Dhruvaraj Subhashchandran <dhruvaraj@in.ibm.com> Create dump manager for each dump type. Currently all types of dumps exist in the same path and under the single dump manager. When there are multiple dumps to be created separate path is needed for creating and managing the dump. this commit is splitting the dump manager into multiple objects without adding any new functionality. There will be only one dump manager process but it will contain seperate dump manager objects for system and BMC dumps as per current scope. Tested the existing dump functions with the build - created bmc dump - created system dump using notify - deleted dump entry - offloaded bmc dump Signed-off-by: Dhruvaraj Subhashchandran <dhruvaraj@in.ibm.com> Change-Id: Id4806660be1f1ba0b3cb6f840ae185a967f05a83
/openbmc/bmcweb/test/redfish-core/lib/
H A D	log_services_dump_test.cpp	diff 0d9462115c53d478ed757ca4a3cccd0acf593781 Wed Jul 13 21:40:19 CDT 2022 Claire Weinan <cweinan@google.com> LogService: Use DeleteAll DBus method in clearDump Update the clearDump() implementation to call the DeleteAll D-Bus method instead of iterating through D-Bus objects representing individual log entries and calling the Delete D-Bus method on each one. (It's more efficient for phosphor-debug-collector to iterate through entries in its DeleteAll method handler than for bmcweb to iterate through them.) It seems like clearDump() wasn't originally implemented using DeleteAll because dumps of various types were under the same D-Bus path namespace at the time and there wasn't a way to selectively clear dumps of only a specific type. The commit at [1] put different dump types under different path namespaces (enabling us to now use DeleteAll). Now clients should see a bit of performance improvement when running the ClearLog action on dump LogServices, due to the reduced number of D-Bus method calls needed to execute ClearLog. Also updated getDumpServiceInfo() to populate the ClearLog action for dump LogServices based on whether their dump manager object implements xyz.openbmc_project.Collection.DeleteAll. Tested: Cleared the fault log containing 100 entries. Ran with the time command several times before and after the change: ``` time curl -k -H "X-Auth-Token: $token" -X POST http://${bmc}/redfish/v1/Managers/bmc/LogServices/FaultLog/Actions/LogService.ClearLog ``` Before the change, "real" time reported was ~1.2s. After the change, "real" time reported was ~0.4s. Forced creation of dump entries and then ran Redfish ClearLog action on each dump type: ``` curl -k -H "X-Auth-Token: $token" -X POST http://${bmc}/redfish/v1/Managers/bmc/LogServices/Dump/Actions/LogService.ClearLog curl -k -H "X-Auth-Token: $token" -X POST http://${bmc}/redfish/v1/Managers/bmc/LogServices/FaultLog/Actions/LogService.ClearLog curl -k -H "X-Auth-Token: $token" -X POST http://${bmc}/redfish/v1/Systems/system/LogServices/Dump/Actions/LogService.ClearLog ``` Then verified that there were no dump LogService entries afterwards: ``` curl -k -H "X-Auth-Token: $token" -X GET http://${bmc}/redfish/v1/Managers/bmc/LogServices/Dump/Entries curl -k -H "X-Auth-Token: $token" -X GET http://${bmc}/redfish/v1/Managers/bmc/LogServices/FaultLog/Entries curl -k -H "X-Auth-Token: $token" -X GET http://${bmc}/redfish/v1/Systems/system/LogServices/Dump/Entries ``` Also verified that the corresponding D-Bus objects were gone from the D-Bus tree after running ClearLog on each dump type: Before ClearLog: busctl tree xyz.openbmc_project.Dump.Manager `-/xyz `-/xyz/openbmc_project `-/xyz/openbmc_project/dump \|-/xyz/openbmc_project/dump/bmc \| `-/xyz/openbmc_project/dump/bmc/entry \| `-/xyz/openbmc_project/dump/bmc/entry/101 \|-/xyz/openbmc_project/dump/faultlog \| `-/xyz/openbmc_project/dump/faultlog/entry \| \|-/xyz/openbmc_project/dump/faultlog/entry/11 \| \|-/xyz/openbmc_project/dump/faultlog/entry/12 \| \|-/xyz/openbmc_project/dump/faultlog/entry/13 \| \|-/xyz/openbmc_project/dump/faultlog/entry/14 \| \|-/xyz/openbmc_project/dump/faultlog/entry/15 \| \|-/xyz/openbmc_project/dump/faultlog/entry/16 \| \|-/xyz/openbmc_project/dump/faultlog/entry/17 \| \|-/xyz/openbmc_project/dump/faultlog/entry/18 \| \|-/xyz/openbmc_project/dump/faultlog/entry/19 \| `-/xyz/openbmc_project/dump/faultlog/entry/20 \|-/xyz/openbmc_project/dump/internal \| `-/xyz/openbmc_project/dump/internal/manager `-/xyz/openbmc_project/dump/system `-/xyz/openbmc_project/dump/system/entry \|-/xyz/openbmc_project/dump/system/entry/3 `-/xyz/openbmc_project/dump/system/entry/4 After ClearLog: busctl tree xyz.openbmc_project.Dump.Manager `-/xyz `-/xyz/openbmc_project `-/xyz/openbmc_project/dump \|-/xyz/openbmc_project/dump/bmc \|-/xyz/openbmc_project/dump/faultlog \|-/xyz/openbmc_project/dump/internal \| `-/xyz/openbmc_project/dump/internal/manager `-/xyz/openbmc_project/dump/system Confirmed that ClearLog action is listed for the following LogServices: /redfish/v1/Managers/bmc/LogServices/Dump /redfish/v1/Managers/bmc/LogServices/FaultLog /redfish/v1/Systems/system/LogServices/Dump Then ran "systemctl stop xyz.openbmc_project.Dump.Manager" (which removes dump manager objects including their xyz.openbmc_project.Collection.DeleteAll interface) and saw that the ClearLog action was no longer listed. Also locally built a version of phosphor-debug-collecor with the interface xyz.openbmc_project.Collection.DeleteAll removed from dump managers and ran it and saw that the ClearLog action wasn't listed. Redfish Service Validator passed on the following URIs (with service xyz.openbmc_project.Dump.Manager running): /redfish/v1/Managers/bmc/LogServices/Dump /redfish/v1/Managers/bmc/LogServices/FaultLog /redfish/v1/Systems/system/LogServices/Dump Note: Most dump LogService unit tests were removed in this patchset since this patchset adds a D-Bus call to getDumpServiceInfo(), and we haven't decided how to mock D-Bus calls for unit testing yet. [1] https://github.com/openbmc/phosphor-debug-collector/commit/fef66a951fe6fe283515480b2c493dfdc2275a95 Signed-off-by: Claire Weinan <cweinan@google.com> Change-Id: Ic5f8f9e3528f521887766d8710bd77f969d8236a
/openbmc/bmcweb/redfish-core/lib/
H A D	log_services.hpp	diff 0d9462115c53d478ed757ca4a3cccd0acf593781 Wed Jul 13 21:40:19 CDT 2022 Claire Weinan <cweinan@google.com> LogService: Use DeleteAll DBus method in clearDump Update the clearDump() implementation to call the DeleteAll D-Bus method instead of iterating through D-Bus objects representing individual log entries and calling the Delete D-Bus method on each one. (It's more efficient for phosphor-debug-collector to iterate through entries in its DeleteAll method handler than for bmcweb to iterate through them.) It seems like clearDump() wasn't originally implemented using DeleteAll because dumps of various types were under the same D-Bus path namespace at the time and there wasn't a way to selectively clear dumps of only a specific type. The commit at [1] put different dump types under different path namespaces (enabling us to now use DeleteAll). Now clients should see a bit of performance improvement when running the ClearLog action on dump LogServices, due to the reduced number of D-Bus method calls needed to execute ClearLog. Also updated getDumpServiceInfo() to populate the ClearLog action for dump LogServices based on whether their dump manager object implements xyz.openbmc_project.Collection.DeleteAll. Tested: Cleared the fault log containing 100 entries. Ran with the time command several times before and after the change: ``` time curl -k -H "X-Auth-Token: $token" -X POST http://${bmc}/redfish/v1/Managers/bmc/LogServices/FaultLog/Actions/LogService.ClearLog ``` Before the change, "real" time reported was ~1.2s. After the change, "real" time reported was ~0.4s. Forced creation of dump entries and then ran Redfish ClearLog action on each dump type: ``` curl -k -H "X-Auth-Token: $token" -X POST http://${bmc}/redfish/v1/Managers/bmc/LogServices/Dump/Actions/LogService.ClearLog curl -k -H "X-Auth-Token: $token" -X POST http://${bmc}/redfish/v1/Managers/bmc/LogServices/FaultLog/Actions/LogService.ClearLog curl -k -H "X-Auth-Token: $token" -X POST http://${bmc}/redfish/v1/Systems/system/LogServices/Dump/Actions/LogService.ClearLog ``` Then verified that there were no dump LogService entries afterwards: ``` curl -k -H "X-Auth-Token: $token" -X GET http://${bmc}/redfish/v1/Managers/bmc/LogServices/Dump/Entries curl -k -H "X-Auth-Token: $token" -X GET http://${bmc}/redfish/v1/Managers/bmc/LogServices/FaultLog/Entries curl -k -H "X-Auth-Token: $token" -X GET http://${bmc}/redfish/v1/Systems/system/LogServices/Dump/Entries ``` Also verified that the corresponding D-Bus objects were gone from the D-Bus tree after running ClearLog on each dump type: Before ClearLog: busctl tree xyz.openbmc_project.Dump.Manager `-/xyz `-/xyz/openbmc_project `-/xyz/openbmc_project/dump \|-/xyz/openbmc_project/dump/bmc \| `-/xyz/openbmc_project/dump/bmc/entry \| `-/xyz/openbmc_project/dump/bmc/entry/101 \|-/xyz/openbmc_project/dump/faultlog \| `-/xyz/openbmc_project/dump/faultlog/entry \| \|-/xyz/openbmc_project/dump/faultlog/entry/11 \| \|-/xyz/openbmc_project/dump/faultlog/entry/12 \| \|-/xyz/openbmc_project/dump/faultlog/entry/13 \| \|-/xyz/openbmc_project/dump/faultlog/entry/14 \| \|-/xyz/openbmc_project/dump/faultlog/entry/15 \| \|-/xyz/openbmc_project/dump/faultlog/entry/16 \| \|-/xyz/openbmc_project/dump/faultlog/entry/17 \| \|-/xyz/openbmc_project/dump/faultlog/entry/18 \| \|-/xyz/openbmc_project/dump/faultlog/entry/19 \| `-/xyz/openbmc_project/dump/faultlog/entry/20 \|-/xyz/openbmc_project/dump/internal \| `-/xyz/openbmc_project/dump/internal/manager `-/xyz/openbmc_project/dump/system `-/xyz/openbmc_project/dump/system/entry \|-/xyz/openbmc_project/dump/system/entry/3 `-/xyz/openbmc_project/dump/system/entry/4 After ClearLog: busctl tree xyz.openbmc_project.Dump.Manager `-/xyz `-/xyz/openbmc_project `-/xyz/openbmc_project/dump \|-/xyz/openbmc_project/dump/bmc \|-/xyz/openbmc_project/dump/faultlog \|-/xyz/openbmc_project/dump/internal \| `-/xyz/openbmc_project/dump/internal/manager `-/xyz/openbmc_project/dump/system Confirmed that ClearLog action is listed for the following LogServices: /redfish/v1/Managers/bmc/LogServices/Dump /redfish/v1/Managers/bmc/LogServices/FaultLog /redfish/v1/Systems/system/LogServices/Dump Then ran "systemctl stop xyz.openbmc_project.Dump.Manager" (which removes dump manager objects including their xyz.openbmc_project.Collection.DeleteAll interface) and saw that the ClearLog action was no longer listed. Also locally built a version of phosphor-debug-collecor with the interface xyz.openbmc_project.Collection.DeleteAll removed from dump managers and ran it and saw that the ClearLog action wasn't listed. Redfish Service Validator passed on the following URIs (with service xyz.openbmc_project.Dump.Manager running): /redfish/v1/Managers/bmc/LogServices/Dump /redfish/v1/Managers/bmc/LogServices/FaultLog /redfish/v1/Systems/system/LogServices/Dump Note: Most dump LogService unit tests were removed in this patchset since this patchset adds a D-Bus call to getDumpServiceInfo(), and we haven't decided how to mock D-Bus calls for unit testing yet. [1] https://github.com/openbmc/phosphor-debug-collector/commit/fef66a951fe6fe283515480b2c493dfdc2275a95 Signed-off-by: Claire Weinan <cweinan@google.com> Change-Id: Ic5f8f9e3528f521887766d8710bd77f969d8236a

Project(s)

Full Search
Definition
Symbol
File Path
History
Type