Thanks!! for review.
Sending out v2 with suggested changes.
On Thursday 23 February 2017 09:22 AM, Stewart Smith wrote:
Michael Ellerman <m...@ellerman.id.au> writes:
Stewart Smith <stew...@linux.vnet.ibm.com> writes:
Vipin K Parashar <vi...@linux.vnet.ibm.com> writes:
On Monday 13 February 2017 06:13 AM, Michael Ellerman wrote:
Vipin K Parashar <vi...@linux.vnet.ibm.com> writes:
OPAL returns OPAL_WRONG_STATE for XSCOM operations
done to read any core FIR which is sleeping, offline.
OK.
Do we know why Linux is causing that to happen?
This issue is originally seen upon running STAF (Software Test
Automation Framework) stress tests and off-lining some cores
with stress tests running.
It can also be re-created after off-lining few cores and following
one of below methods.
1. Executing Linux "sensors" command
2. Reading contents of file /sys/class/hwmon/hwmon0/tempX_input,
where X is offline CPU.
Its "opal_get_sensor_data" Linux API that that triggers
OPAL call "opal_sensor_read", performing XSCOM ops here.
If core is found sleeping/offline Linux throws up
"opal_error_code: Unexpected OPAL error" error onto console.
Currently Linux isn't aware about OPAL_WRONG_STATE return code
from OPAL. Thus it prints "Unexpected OPAL error" message, same
as it would log for any unknown OPAL return codes.
Seeing this error over console has been a concern for Test and
would puzzle real user as well. This patch makes Linux aware about
OPAL_WRONG_STATE return code from OPAL and stops printing
"Unexpected OPAL error" message onto console for OPAL fails
with OPAL_WRONG_STATE
Ahh... so this is a DTS sensor, which indeed is just XSCOMs and we
return the xscom_read return code in event of error.
I would argue that converting to EIO in that instance is probably
correct... or EAGAIN? EAGAIN may be more correct in the situation where
the core is just sleeping.
What kind of offlining are you doing?
Arguably, the correct behaviour would be to remove said sensors when the
core is offline.
Right, that would be ideal. There appear to be at least two other hwmon
drivers that are CPU hotplug aware (coretemp and via-cputemp).
But perhaps it's not possible to work out which sensors are attached to
which CPU etc., I haven't looked in detail.
Each core-temp@ sensor has a ibm,pir property, so linking back to what
core shouldn't be too hard. For mem-temp@ sensors, we have the chip-id.
In that case changing just opal_get_sensor_data() to handle
OPAL_WRONG_STATE would be OK, with a comment explaining that we might be
asked to read a sensor on an offline CPU and we aren't able to detect
that.
Agree.
