Skip to content
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

Power cap setting is not working properly on Palmetto #42

Closed
mkumatag opened this issue Feb 3, 2016 · 7 comments
Closed

Power cap setting is not working properly on Palmetto #42

mkumatag opened this issue Feb 3, 2016 · 7 comments
Labels

Comments

@mkumatag
Copy link
Contributor

mkumatag commented Feb 3, 2016

Powercap settings are not really working properly on Palmetto box. Discussed with Yi LI - found to be code is written only for Barreleye and not dynamic enough to deal both platform.

@nkskjames
Copy link
Contributor

Can you elaborate on this? What is specific to Barreleye?

@mkumatag
Copy link
Contributor Author

mkumatag commented Feb 4, 2016

I discussed with Yi Li, he mentioned that in sensor_manager2.py, sysfs_attr is hardcoded to work for Barreleye platform, which should be different a path for palmetto platform.

## instantiate non-polling sensors
## these don't need to be in seperate process
## TODO: this should not be hardcoded

obj_path = OBJ_PATH+"/host/PowerCap"
sensor_obj = Sensors.PowerCap(bus,obj_path)
## hwmon3 is default for master OCC on Barreleye.
## should rewrite sensor_manager to remove hardcode
sensor_obj.sysfs_attr = "/sys/class/hwmon/hwmon3/user_powercap"
root_sensor.add(obj_path,sensor_obj)

adamliyi added a commit to adamliyi/skeleton that referenced this issue Feb 19, 2016
Currently master OCC hwmon sysfs path is hardcoded to '/sys/class/hwmon/hwmon3/'.
This make the '/org/openbmc/sensors/host/PowerCap' interface cannot work when
master OCC is initilized as hwmon device other than 'hwmon3'.

This would fix the issue: openbmc#42

Signed-off-by: Yi Li <adamliyi@msn.com>
@adamliyi
Copy link
Member

Fixed here: #48
Tested on Palmetto.

adamliyi added a commit to adamliyi/skeleton that referenced this issue Feb 26, 2016
…ap object

Currently master OCC hwmon sysfs path is hardcoded to '/sys/class/hwmon/hwmon3/'.
This make the '/org/openbmc/sensors/host/PowerCap' interface cannot work when
master OCC is initilized as hwmon device other than 'hwmon3'.

'usr_powercap' attribute should be searched when OCC is active.
When skeleton creates 'PowerCap' objects, OCC may not be active.
So do the search each time setting power cap. Raise an exception when
there is no 'user_powercap' attribute.

This would fix the issue: openbmc#42

Also raise an exception when setting power cap fails. The exception
will be returned to REST API caller. This would fix the issue:
openbmc#43

Signed-off-by: Yi Li <adamliyi@msn.com>
adamliyi added a commit to adamliyi/skeleton that referenced this issue Feb 26, 2016
…ap object

Currently master OCC hwmon sysfs path is hardcoded to '/sys/class/hwmon/hwmon3/'.
This make the '/org/openbmc/sensors/host/PowerCap' interface cannot work when
master OCC is initilized as hwmon device other than 'hwmon3'.

'usr_powercap' attribute should be searched when OCC is active.
When skeleton creates 'PowerCap' objects, OCC may not be active.
So do the search each time setting power cap. Raise an exception when
there is no 'user_powercap' attribute.

This would fix the issue: openbmc#42

Also raise an exception when setting power cap fails. The exception
will be returned to REST API caller. This would fix the issue:
openbmc#43

Signed-off-by: Yi Li <adamliyi@msn.com>
@adamliyi
Copy link
Member

Resubmitted a PR to fix this issue: #50
Each time setting PowerCap, skeleton will search for 'user_powercap" in '/sys/class/hwmon'. If not found, an exception will be returned. This will happen when OCC is not active, or for some reason, OCC is active, OCC device is not initialized.

adamliyi added a commit to adamliyi/skeleton that referenced this issue Feb 26, 2016
…ap object

Currently master OCC hwmon sysfs path is hardcoded to '/sys/class/hwmon/hwmon3/'.
This make the '/org/openbmc/sensors/host/PowerCap' interface cannot work when
master OCC is initilized as hwmon device other than 'hwmon3'.

'usr_powercap' attribute should be searched when OCC is active.
When skeleton creates 'PowerCap' objects, OCC may not be active.
So do the search each time setting power cap. Raise an exception when
there is no 'user_powercap' attribute.

This would fix the issue: openbmc#42

Also raise an exception when setting power cap fails. The exception
will be returned to REST API caller. Need to specify the exception
name to trigger a '400' return code.
This would fix the issue:
openbmc#43

Signed-off-by: Yi Li <adamliyi@msn.com>
adamliyi added a commit to adamliyi/skeleton that referenced this issue Feb 26, 2016
…ap object

Currently master OCC hwmon sysfs path is hardcoded to '/sys/class/hwmon/hwmon3/'.
This make the '/org/openbmc/sensors/host/PowerCap' interface cannot work when
master OCC is initilized as hwmon device other than 'hwmon3'.

'usr_powercap' attribute should be searched when OCC is active.
When skeleton creates 'PowerCap' objects, OCC may not be active.
So do the search each time setting power cap. Raise an exception when
there is no 'user_powercap' attribute.

This would fix the issue: openbmc#42

Also raise an exception when setting power cap fails. The exception
will be returned to REST API caller. Need to specify the exception
name to trigger a '400' return code.
This would fix the issue:
openbmc#43

Signed-off-by: Yi Li <adamliyi@msn.com>
@adamliyi
Copy link
Member

If setting error, would expect an error code like bellow:

curl -c cjar -b cjar -k -H "Content-Type: application/json" -X POST -d "{"data": [ 12000 ]}" https://9.3.23.24/org/openbmc/sensors/host/PowerCap/action/setValue
{
"data": {
"description": "org.freedesktop.DBus.Python.TypeError: Cannot find user_powercap hwmon attribute, check occ status."
},
"message": "400 Bad Request",
"status": "error"
}

adamliyi added a commit to adamliyi/skeleton that referenced this issue Mar 4, 2016
…ap object

Currently master OCC hwmon sysfs path is hardcoded to '/sys/class/hwmon/hwmon3/'.
This make the '/org/openbmc/sensors/host/PowerCap' interface cannot work when
master OCC is initilized as hwmon device other than 'hwmon3'.

'usr_powercap' attribute should be searched when OCC is active.
When skeleton creates 'PowerCap' objects, OCC may not be active.
So do the search each time setting power cap. Raise an exception when
there is no 'user_powercap' attribute.
Fixes: openbmc#42

Also raise an exception when setting power cap fails. The exception
will be returned to REST API caller. Need to specify the exception
name to trigger a '400' return code.
Fixes: openbmc#43

Add code to validate input user powercap value.

Changed the logic of "reading powercap" using PowerCap.getValue().
Previously PowerCap.getValue() returns current user set powercap value.
Now PowerCap.getValue() returns actual system powercap reading from OCC.

Signed-off-by: Yi Li <adamliyi@msn.com>
adamliyi added a commit to adamliyi/skeleton that referenced this issue Mar 4, 2016
…ap object

Currently master OCC hwmon sysfs path is hardcoded to '/sys/class/hwmon/hwmon3/'.
This make the '/org/openbmc/sensors/host/PowerCap' interface cannot work when
master OCC is initilized as hwmon device other than 'hwmon3'.

'usr_powercap' attribute should be searched when OCC is active.
When skeleton creates 'PowerCap' objects, OCC may not be active.
So do the search each time setting power cap. Raise an exception when
there is no 'user_powercap' attribute.
Fixes: openbmc#42

Also raise an exception when setting power cap fails. The exception
will be returned to REST API caller. Need to specify the exception
name to trigger a '400' return code.
Fixes: openbmc#43

Add code to validate input user powercap value.

Changed the logic of "reading powercap" using PowerCap.getValue().
Previously PowerCap.getValue() returns current user set powercap value.
Now PowerCap.getValue() returns actual system powercap reading from OCC.

Signed-off-by: Yi Li <adamliyi@msn.com>
@adamliyi
Copy link
Member

@mkumatag , I just set up the environment on a Palmetto: 9.3.164.149
Could you please verify this issue?
Thanks,
-Yi

@nkskjames nkskjames added the bug label Mar 17, 2016
@mkumatag
Copy link
Contributor Author

Tested on that machine and working fine.
Test results:

Get System Power Consumption :: Get the current system power consu... | PASS |

Test Occ Powercap :: This suite is for testing OCC: Power capping ... | PASS |
6 critical tests, 6 passed, 0 failed

6 tests total, 6 passed, 0 failed

Output: /home/manjunath/git/openbmc-automation/output.xml
Log: /home/manjunath/git/openbmc-automation/log.html
Report: /home/manjunath/git/openbmc-automation/report.html
______________________________________________________________________________________________ summary ______________________________________________________________________________________________
custom: commands succeeded
congratulations :)
[manjunath@oc1275007250 openbmc-automation]$

adamliyi added a commit to adamliyi/skeleton that referenced this issue May 10, 2016
…ap object

Currently master OCC hwmon sysfs path is hardcoded to '/sys/class/hwmon/hwmon3/'.
This make the '/org/openbmc/sensors/host/PowerCap' interface cannot work when
master OCC is initilized as hwmon device other than 'hwmon3'.

'usr_powercap' attribute should be searched when OCC is active.
When skeleton creates 'PowerCap' objects, OCC may not be active.
So do the search each time setting power cap. Raise an exception when
there is no 'user_powercap' attribute.
Fixes: openbmc#42

Also raise an exception when setting power cap fails. The exception
will be returned to REST API caller. Need to specify the exception
name to trigger a '400' return code.
Fixes: openbmc#43

Add code to validate input user powercap value.

Changed the logic of "reading powercap" using PowerCap.getValue().
Previously PowerCap.getValue() returns current user set powercap value.
Now PowerCap.getValue() returns actual system powercap reading from OCC.

Signed-off-by: Yi Li <adamliyi@msn.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants