| /openbmc/phosphor-hwmon/ |
| H A D | fan_speed.cpp | diff 1e6324fa4fc233c3f2913b3d5278aa06e45ff42f Thu Jun 01 16:07:05 CDT 2017 Patrick Venture <venture@google.com> Don't exit program on sysfs read failures.
We have an unreliable fan in one of the test systems and at present if
the sysfs entry is unavailable or returns failure, then the program will
exit. The program could be serving many sensors, and any one failure
will cause it to exit. This is true not only when initially creating
the sensors, but also if any sensor read fails at run-time.
Testing: I verified the program logged the failures, which may not
be ideal if there is a buggy sensor, but, I also ran it and managed
to catch it where the sensor wasn't there initially and it cleanly
reported only the sensors that were responsive and didn't just exit.
There is certainly a case to be made for re-scanning periodically if the
sensor returns or there was a timing issue, and there is a separate bug
for that. This commit means only to make the program more robust on
failure.
Change-Id: I310a3e3c0e0ea86e439341a296b741ded18f46f2
Signed-off-by: Patrick Venture <venture@google.com>
|
| H A D | readd.cpp | diff 1e6324fa4fc233c3f2913b3d5278aa06e45ff42f Thu Jun 01 16:07:05 CDT 2017 Patrick Venture <venture@google.com> Don't exit program on sysfs read failures.
We have an unreliable fan in one of the test systems and at present if
the sysfs entry is unavailable or returns failure, then the program will
exit. The program could be serving many sensors, and any one failure
will cause it to exit. This is true not only when initially creating
the sensors, but also if any sensor read fails at run-time.
Testing: I verified the program logged the failures, which may not
be ideal if there is a buggy sensor, but, I also ran it and managed
to catch it where the sensor wasn't there initially and it cleanly
reported only the sensors that were responsive and didn't just exit.
There is certainly a case to be made for re-scanning periodically if the
sensor returns or there was a timing issue, and there is a separate bug
for that. This commit means only to make the program more robust on
failure.
Change-Id: I310a3e3c0e0ea86e439341a296b741ded18f46f2
Signed-off-by: Patrick Venture <venture@google.com>
|
| H A D | targets.hpp | diff 1e6324fa4fc233c3f2913b3d5278aa06e45ff42f Thu Jun 01 16:07:05 CDT 2017 Patrick Venture <venture@google.com> Don't exit program on sysfs read failures.
We have an unreliable fan in one of the test systems and at present if
the sysfs entry is unavailable or returns failure, then the program will
exit. The program could be serving many sensors, and any one failure
will cause it to exit. This is true not only when initially creating
the sensors, but also if any sensor read fails at run-time.
Testing: I verified the program logged the failures, which may not
be ideal if there is a buggy sensor, but, I also ran it and managed
to catch it where the sensor wasn't there initially and it cleanly
reported only the sensors that were responsive and didn't just exit.
There is certainly a case to be made for re-scanning periodically if the
sensor returns or there was a timing issue, and there is a separate bug
for that. This commit means only to make the program more robust on
failure.
Change-Id: I310a3e3c0e0ea86e439341a296b741ded18f46f2
Signed-off-by: Patrick Venture <venture@google.com>
|
| H A D | sysfs.hpp | diff 1e6324fa4fc233c3f2913b3d5278aa06e45ff42f Thu Jun 01 16:07:05 CDT 2017 Patrick Venture <venture@google.com> Don't exit program on sysfs read failures.
We have an unreliable fan in one of the test systems and at present if
the sysfs entry is unavailable or returns failure, then the program will
exit. The program could be serving many sensors, and any one failure
will cause it to exit. This is true not only when initially creating
the sensors, but also if any sensor read fails at run-time.
Testing: I verified the program logged the failures, which may not
be ideal if there is a buggy sensor, but, I also ran it and managed
to catch it where the sensor wasn't there initially and it cleanly
reported only the sensors that were responsive and didn't just exit.
There is certainly a case to be made for re-scanning periodically if the
sensor returns or there was a timing issue, and there is a separate bug
for that. This commit means only to make the program more robust on
failure.
Change-Id: I310a3e3c0e0ea86e439341a296b741ded18f46f2
Signed-off-by: Patrick Venture <venture@google.com>
|
| H A D | sysfs.cpp | diff 1e6324fa4fc233c3f2913b3d5278aa06e45ff42f Thu Jun 01 16:07:05 CDT 2017 Patrick Venture <venture@google.com> Don't exit program on sysfs read failures.
We have an unreliable fan in one of the test systems and at present if
the sysfs entry is unavailable or returns failure, then the program will
exit. The program could be serving many sensors, and any one failure
will cause it to exit. This is true not only when initially creating
the sensors, but also if any sensor read fails at run-time.
Testing: I verified the program logged the failures, which may not
be ideal if there is a buggy sensor, but, I also ran it and managed
to catch it where the sensor wasn't there initially and it cleanly
reported only the sensors that were responsive and didn't just exit.
There is certainly a case to be made for re-scanning periodically if the
sensor returns or there was a timing issue, and there is a separate bug
for that. This commit means only to make the program more robust on
failure.
Change-Id: I310a3e3c0e0ea86e439341a296b741ded18f46f2
Signed-off-by: Patrick Venture <venture@google.com>
|
| H A D | mainloop.cpp | diff 1e6324fa4fc233c3f2913b3d5278aa06e45ff42f Thu Jun 01 16:07:05 CDT 2017 Patrick Venture <venture@google.com> Don't exit program on sysfs read failures.
We have an unreliable fan in one of the test systems and at present if
the sysfs entry is unavailable or returns failure, then the program will
exit. The program could be serving many sensors, and any one failure
will cause it to exit. This is true not only when initially creating
the sensors, but also if any sensor read fails at run-time.
Testing: I verified the program logged the failures, which may not
be ideal if there is a buggy sensor, but, I also ran it and managed
to catch it where the sensor wasn't there initially and it cleanly
reported only the sensors that were responsive and didn't just exit.
There is certainly a case to be made for re-scanning periodically if the
sensor returns or there was a timing issue, and there is a separate bug
for that. This commit means only to make the program more robust on
failure.
Change-Id: I310a3e3c0e0ea86e439341a296b741ded18f46f2
Signed-off-by: Patrick Venture <venture@google.com>
|