-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Mellanox]PSU sensors dynamic configuration #18528
[Mellanox]PSU sensors dynamic configuration #18528
Conversation
482cb5d
to
0fd69b7
Compare
/azpw run Azure.sonic-buildimage |
/AzurePipelines run Azure.sonic-buildimage |
Azure Pipelines successfully started running 1 pipeline(s). |
0fd69b7
to
1060d66
Compare
db8c1f1
to
1060d66
Compare
1f70f0e
to
aa1f312
Compare
/AzurePipelines run Azure.sonic-buildimage |
Commenter does not have sufficient privileges for PR 18528 in repo sonic-net/sonic-buildimage |
/azpw run Azure.sonic-buildimage |
/AzurePipelines run Azure.sonic-buildimage |
Azure Pipelines successfully started running 1 pipeline(s). |
9413eb3
to
33e3d9b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM but you are missing recent new device SN5400. Please add the relevant changes to this device as well
Signed-off-by: Yuanzhe, Liu <yualiu@nvidia.com>
I have updated relevant changes according to SN5400 sensor configuration file. |
/azpw ms_conflict |
add a script to dynamically update the original sensors.conf psu section to match the currently used psu model. add a json file to store related platform and psu info. simx revision is irrelevant, so there is no change on it. Signed-off-by: Yuanzhe, Liu <yualiu@nvidia.com>
once the get_model api detect a psu model changing, it would firstly regenerate sensors.conf and then restart sensord to active the new configuration. Signed-off-by: Yuanzhe, Liu <yualiu@nvidia.com>
d6d9dfb
to
2f12d00
Compare
/azpw ms_conflict -f |
- Why I did it Previously, the PSU sensor configuration inside sensors.conf is hardcoded for each platform, allowing no flexibility for other PSU combination possibilities. However, there exists a scenario that user has a second source of PSU which has different sensors compared to the original sensors.conf. Thereby it requires the system to have the ability to dynamically detect the PSU model in using and load relevant sensor’s configuration file. - How I did it This PR involves a new script and a corresponding data file which contains all PSU model’s sensor configuration info. The script reads the hardware PSU information through hw-management and determines its model. Based on that, it searches for the corresponding pre-defined PSU sensor data, integrate them into the sensors.conf, and let PMON copy it for further loading by lm-sensor. It also integrates the script inside the platform's get_model() API. Therefore, each time this API is called by the psud code, it checks whether there has been a change in the PSU model. If a change is detected, it updates the PSU sensors configuration by calling the script. - How to verify it use sensors command and check the psu section is rightly labeled. Signed-off-by: Yuanzhe, Liu <yualiu@nvidia.com>
Cherry-pick PR to 202405: #19291 |
- Why I did it Previously, the PSU sensor configuration inside sensors.conf is hardcoded for each platform, allowing no flexibility for other PSU combination possibilities. However, there exists a scenario that user has a second source of PSU which has different sensors compared to the original sensors.conf. Thereby it requires the system to have the ability to dynamically detect the PSU model in using and load relevant sensor’s configuration file. - How I did it This PR involves a new script and a corresponding data file which contains all PSU model’s sensor configuration info. The script reads the hardware PSU information through hw-management and determines its model. Based on that, it searches for the corresponding pre-defined PSU sensor data, integrate them into the sensors.conf, and let PMON copy it for further loading by lm-sensor. It also integrates the script inside the platform's get_model() API. Therefore, each time this API is called by the psud code, it checks whether there has been a change in the PSU model. If a change is detected, it updates the PSU sensors configuration by calling the script. - How to verify it use sensors command and check the psu section is rightly labeled. Signed-off-by: Yuanzhe, Liu <yualiu@nvidia.com>
- Why I did it Previously, the PSU sensor configuration inside sensors.conf is hardcoded for each platform, allowing no flexibility for other PSU combination possibilities. However, there exists a scenario that user has a second source of PSU which has different sensors compared to the original sensors.conf. Thereby it requires the system to have the ability to dynamically detect the PSU model in using and load relevant sensor’s configuration file. - How I did it This PR involves a new script and a corresponding data file which contains all PSU model’s sensor configuration info. The script reads the hardware PSU information through hw-management and determines its model. Based on that, it searches for the corresponding pre-defined PSU sensor data, integrate them into the sensors.conf, and let PMON copy it for further loading by lm-sensor. It also integrates the script inside the platform's get_model() API. Therefore, each time this API is called by the psud code, it checks whether there has been a change in the PSU model. If a change is detected, it updates the PSU sensors configuration by calling the script. - How to verify it use sensors command and check the psu section is rightly labeled. Signed-off-by: Yuanzhe, Liu <yualiu@nvidia.com>
- Why I did it Previously, the PSU sensor configuration inside sensors.conf is hardcoded for each platform, allowing no flexibility for other PSU combination possibilities. However, there exists a scenario that user has a second source of PSU which has different sensors compared to the original sensors.conf. Thereby it requires the system to have the ability to dynamically detect the PSU model in using and load relevant sensor’s configuration file. - How I did it This PR involves a new script and a corresponding data file which contains all PSU model’s sensor configuration info. The script reads the hardware PSU information through hw-management and determines its model. Based on that, it searches for the corresponding pre-defined PSU sensor data, integrate them into the sensors.conf, and let PMON copy it for further loading by lm-sensor. It also integrates the script inside the platform's get_model() API. Therefore, each time this API is called by the psud code, it checks whether there has been a change in the PSU model. If a change is detected, it updates the PSU sensors configuration by calling the script. - How to verify it use sensors command and check the psu section is rightly labeled. Signed-off-by: Yuanzhe, Liu <yualiu@nvidia.com>
Cherry-pick PR to 202311: #19801 |
- Why I did it Previously, the PSU sensor configuration inside sensors.conf is hardcoded for each platform, allowing no flexibility for other PSU combination possibilities. However, there exists a scenario that user has a second source of PSU which has different sensors compared to the original sensors.conf. Thereby it requires the system to have the ability to dynamically detect the PSU model in using and load relevant sensor’s configuration file. - How I did it This PR involves a new script and a corresponding data file which contains all PSU model’s sensor configuration info. The script reads the hardware PSU information through hw-management and determines its model. Based on that, it searches for the corresponding pre-defined PSU sensor data, integrate them into the sensors.conf, and let PMON copy it for further loading by lm-sensor. It also integrates the script inside the platform's get_model() API. Therefore, each time this API is called by the psud code, it checks whether there has been a change in the PSU model. If a change is detected, it updates the PSU sensors configuration by calling the script. - How to verify it use sensors command and check the psu section is rightly labeled. Signed-off-by: Yuanzhe, Liu <yualiu@nvidia.com>
Why I did it
Previously, the PSU sensor configuration inside sensors.conf is hardcoded for each platform, allowing no flexibility for other PSU combination possibilities. However, there exists a scenario that user has a second source of PSU which has different sensors compared to the original sensors.conf. Thereby it requires the system to have the ability to dynamically detect the PSU model in using and load relevant sensor’s configuration file.
How I did it
This PR involves a new script and a corresponding data file which contains all PSU model’s sensor configuration info. The script reads the hardware PSU information through hw-management and determines its model. Based on that, it searches for the corresponding pre-defined PSU sensor data, integrate them into the sensors.conf, and let PMON copy it for further loading by lm-sensor.
It also integrates the script inside the platform's get_model() API. Therefore, each time this API is called by the psud code, it checks whether there has been a change in the PSU model. If a change is detected, it updates the PSU sensors configuration by calling the script.
How to verify it
use
sensors
command and check the psu section is rightly labeled.Which release branch to backport (provide reason below if selected)
Tested branch (Please provide the tested image version)
Description for the changelog
Link to config_db schema for YANG module changes
A picture of a cute animal (not mandatory but encouraged)