Christian Hammers wrote: > Hello > > It seems to be related to the above mentioned bug number but the FAQ was > a bit unclear how to include the ticket number in the subject :) > > My problem is that sensors sometimes reports confusing values i.e. > - it prints ALERT although the corresponding values are fine, the ALERT > then vanished in the next read Yup, that is what the sensor chip reports. It is up to _you_ properly process the signals to suit your requirements. ALERT is typically cleared by the act of reading a value. > - sensor values give suddenly 0 or arbitrary values The sensor chips operate in an extremely noisy electrical environment, stuff happens, your application software may denounce this. > - configured limits are 0 for one or two reads and then go back to the > defined value Again nature of the beast, your expectations do not match reality :o) > - chassis intrusion is set just for a couple of seconds So denounce it? > > This makes it absolutely unusable for monitoring in production use. No, you expect a kernel driver to do the work of a custom user-space solution, IOW you want the kernel to enforce policy. The kernel + drivers do not enforce policy, they control access to resources. > I had have this before on several other mainboards, too. It can be > circumvented by reading the sensors output trice and only alert if you > get an alert in all three readings but this should not be the task of > the user :) On this mainboard here it is worse than ever though. Yes, because you need to better understand the issues, when everything looks wrong, it is time to check the viewer. No? > Data for this mainboard although the problem is more general and > experienced on several other models and brands, too: I don't do free consulting. Grant.
