lm_sensors 2.9.1 My hardware needs the fan divisors set to report correct values. They are set with sensors -s by the lm_sensors service at boot time. Unfortunately sensors -s is not reliable. It does not seem to set the divisors right the first time it
Created attachment 6503 [details] dmesg
Created attachment 6504 [details] lspci
Your report is too vague to be useful. "sensors" is used without problems by too many people for your bold statement that "sensors -s is unreliable" to be true. This has to be specific to your hardware or the way you use it. Which motherboard do you have the problem with? Which hardware monitoring chip does it use? Please provide the output of sensors-detect after you unloaded all i2c chip drivers. Please also provide the sensors.conf file you are using. You say "sensors -s does not seem to set the divisors right". Please explain in detail what happens. What is the value before you run "sensors -s", what value are you trying to set it to, what value is it actually set to? Do you observe any problem with the fan min limit not being set properly either? Or just any problem other that with fan clock dividers? I hope you realize that having "sensors -s retry automatically as many times as required" would be an ugly hack, and this will certainly not happen. If "sensors -s" fails to do what we asked it to do, this has to be a bug either in sensors, libsensors, the SMBus driver or the hardware monitoring driver. Or a user error. Whatever, let's fix the problem where it is rather than using brute force to walk over it.
The motherboards affected are the Gigabyte GA-K8N Ultra 9 (nForce4 Ultra + ITF8712F chipset) : http://www.gigabyte.com.tw/MotherBoard/Products/Products_GA-K8N%20Ultra-9.htm and the GA-7VAX (KT400 + IT8705) : http://www.gigabyte.com.tw/MotherBoard/Products/Products_GA-7VAX.htm (don't have this one anymore, it died on me two months ago) On both systems sensors chips were detected correctly (at least when they work they give more or less correct readings for the fans) On both systems sensors -s must set the fan divisor to 8 (default is 4 I think) sensors -s is run at boot by the lm_sensors service What happens is is doesn't set this divisor. Re-executing sensors -s & sensors later manually works, but the initial command fails. However it clearly touches the chipset. On the nVidia board the bios is configured to beep on fan failure. It starts beeping as soon as sensors -s is executed by the init service, and stops when sensors -s is re-executed manually later I can try to record sensors values before the first sensors -s, after it and after the second sensors -s call if you want.
Created attachment 6507 [details] sensors.conf
Created attachment 6508 [details] lm_sensors service
Created attachment 6509 [details] rc.local workaround
Created attachment 6510 [details] /etc/sysconfig/lm_sensors
Yes, please provide the output of "sensors" before the first "sensors -s", after it, and after the second one. I think I see what's wrong, but I need this for confirmation.
Created attachment 6512 [details] Before initial sensors -s
Created attachment 6513 [details] After initial sensors -s (BEEEEEP)
Created attachment 6514 [details] After final sensors -s (all ok)
Nothing overly obvious I fear - it seems reading 2 and 3 are similar. I do remember that with the GA-7VAX the divisor was not set until the second sensors -s , but maybe the kernel changed since (or maybe the GA-7VAX had a different problem) Also, just repeating sensors -s in the init script does not work. It seems there is some time limit before the second sensors -s can have its effect If I have to reinstall FC4 while moving to a new RAID root I'll retry with the original FC4 kernel
The hardware monitoring drivers cache the register values for a short period of time (1.5 second for the it87) so as to prevent I/O saturation and limit monitoring interruptions. The first and second "sensors" outputs are too suspiciously similar, so it's clear to me that the second hit the cache and didn't actually read the register values. You would need to add a "sleep 2" between both "sensors" commands to make sure the register values are read again. In particular, you would see ALARM flags (else your system wouldn't beep). Secondly, the chip itself caches the alarms, in the sense that it doesn't clear them before they have been read at least once. This explains why you have to call "sensors" for your system to stop beeping. The combination of both mechanisms explains that you had difficulties to figure out what was going on, but are not actually the cause of your trouble IMHO. Your main problem is a bogus sensors.conf file. In the fans section, you are setting the fan low limits before the fan clock dividers. This is wrong. The default configuration file has a pretty clear comment about this: # A 'set fan1_div' statement must go before a 'set fan1_min' statement, # because the driver uses the divisor in calculating the minimum. Try switching the "set" lines, I expect this to solve your problem. I think it is similar to this report: http://qa.mandriva.com/show_bug.cgi?id=16755#c3
The bogus sensors.conf file is the one shipped by the lm_sensors project :) I'll test your changes now to see how it goes
No. I double checked the lm_sensors' default configuration file, and it doesn't set any fan clock divider for the it87 driver. You must have added these lines yourself.
Created attachment 6523 [details] New sensors.conf With this new configuration file everything works -> the default lm_sensors conf file should be fixed -> should not lm_sensors reorder configuration directives automagically to avoid this ?
BTW "Ground" is stable at 4.08V Does this actually mean something ? What would be a good monitoring range for this measure ?
Ok, you're right lm_sensors 2.9.1 does not have these lines They were probably a leftover from some previous version or one online lm_sensors howto
It would certainly be great if libsensors could handle that kind of dependency automatically, but it currently doesn't. Adding this feature would require some redesign of the configuration file parser, won't be easy. I'm not into that myself. Patches are welcome though :) +4.08 V is the max raw voltage the chip can measure (255 * 0.16 mV). Such measurement usually means the input is improperly wired. You have this value for in8, which is dedicated to the battery voltage. However, in bug #5575, your sensors output has a valid Vbat value, so it has to be properly wired. I can't say why it is incorrect now. Could be a bug in the it87 driver, or a motherboard issue (either hardware or BIOS). in8 is particular in the it87 driver, in that it is only sensed once. The idea is to avoid wasting the battery's energy. You could try loading the it87 driver with update_vbat=1 temporarily, so that in8 is sensed everytime, and see what happens. Your question about the range is irrelevant, because in8 does not have associated limit registers (as you can see from sensors output). Comments about your new configuration file: * in8 is Vbat, not Ground. * vid is not a "second Vcore sensor", it is the nominal voltage of your CPU. It is a digital value, while in0 is an analog measurement.