Hi Jukka,
On Tue, Aug 13, 2013 at 1:10 AM, Jukka Nikulainen <jukka.nikulainen@xxxxxxxxxxx> wrote:
There are really only two questions I have.
Firstly: Did I understand correctly that only using the slightly modified it87-driver 'sensors' was able to report the temperature readings correctly?
It needs more testing, but the short answer is: yes.
After reading the thread I was under the impression that changes in the hwmon-vid.c file were only needed to get sane readings about voltages. Is this correct? I have built the case for my computer and I am only interested in monitoring the temperatures.
The changes to hwmon-vid.c were to correctly interpret the VID bits -- bits that store a coded value representing the CPU voltage. You can get more information about that from Jean Delvare via lm-sensors@xxxxxxxxxxxxxx. He, not I, wrote the changes for hwmon-vid.c as a matter of fact.
Secondly: I assume that the correct work-flow is to make your changes in the it87 source code, compile the file, replace the driver and modprobe it. I have compiled programs before but not very frequently and nothing kernel-related. I'm sure that the procedure is dead-simple, but I still have a few questions that even extensive googling didn't answer. For example, are the relevant kernel header files the only dependency?
Building a module out-of-tree is possible (using just the kernel header files). I am aware that this may result in the cleanest results for a debian system, since you can use a stock debian kernel and load your out-of-tree module.
However, I suggest taking a different approach. This module in particular is highly experimental, as in: I think I'm the only other person who has actually tried it. I believe that is a good reason not to use a stock kernel. If you use a stock kernel, your results are not representative of the simplest "base case" for debugging, and this particular chip would benefit from more testing of the base case. It would also be possible to use a stock debian kernel + out-of-tree module, and then carefully attempt to replicate your problem on a kernel compiled from source any time you want to discuss it on the lm-sensors list... but that's a whole lot of extra work for you :)
However, I suggest taking a different approach. This module in particular is highly experimental, as in: I think I'm the only other person who has actually tried it. I believe that is a good reason not to use a stock kernel. If you use a stock kernel, your results are not representative of the simplest "base case" for debugging, and this particular chip would benefit from more testing of the base case. It would also be possible to use a stock debian kernel + out-of-tree module, and then carefully attempt to replicate your problem on a kernel compiled from source any time you want to discuss it on the lm-sensors list... but that's a whole lot of extra work for you :)
Do you know of any (possibly generic) makefile for the drivers? I was also unable to find any version of it87.c that would readily incorporate your changes; has it been published anywhere?
You can get the source I used for it87.c from the latest kernel sources and then apply the patch. If the patch does not apply well to the latest it87.c, I'm interested in updating the patch so it does apply cleanly to the latest kernel. (I view the patch as a relatively simple change, which should be highly portable.)
Good luck and happy hacking,
David
P.S. I have reason to believe that the it87 device we are talking about is actually an emulation running on an 8051 co-processor, specifically the EC (Embedded Controller) in the AMD A85 Hudson chipset. The it87 emulation is poorly written in the 8051 code and can result in unexpected effects -- bugs. I have specifically seen the sensor stop updating (as if it just stopped sampling values).
David
P.S. I have reason to believe that the it87 device we are talking about is actually an emulation running on an 8051 co-processor, specifically the EC (Embedded Controller) in the AMD A85 Hudson chipset. The it87 emulation is poorly written in the 8051 code and can result in unexpected effects -- bugs. I have specifically seen the sensor stop updating (as if it just stopped sampling values).
Therefore, the patch may be somewhat useful for getting sensor data in linux, but it is not going to be the final solution for getting good sensor data from the F2A85-M motherboard. Or in other words, I don't plan to take the patch all the way to inclusion in the Linux kernel.
_______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
