Dealing with a sensor which doesn't have valid reading until host is powered up

[James Feist]

On 9/2/2020 3:07 PM, Alex Qiu wrote:
> Hi James,
> 
> I just tried, now I have no reading at all... I saw you marked your pull 
> request to work in progress. I'll wait for further updates...
> 
> - Alex Qiu

Hi Alex,

Yes I ran into the same issue, I was originally using the tcp socket, 
then calling read() directly, and that 'worked' and may work for your 
use case, but mine the driver timeout still slowed down the sensor to an 
non-functional state. I pushed a patch to CPU sensor to make it fail 
faster, because in the case peci is down, you have bigger problems then 
sensors responding slow. It sounds like we aren't the first ones to hit 
this problem 
https://lists.ozlabs.org/pipermail/openbmc/2017-May/007557.html.

I'm thinking the only 'full proof' ways to fix this sort of things are:

1. Have some way to check state that you're good to read.
2. Handle reading in threads separate from d-bus.
3. Maybe avoid using the sysfs handles as they don't seem to respond 
correctly to epoll as they always respond ready to read.

-James