From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020809 Description of problem: When running sensors-detect on ECS K7S5A motherboard, the ISA bus scan gives several error messages: "Character in "C" format wrapped at /usr/sbin/sensors-detect line 963." and fails to detect the ITE8705F chip on the motherboard. Version-Release number of selected component (if applicable): lm_sensors-2.6.3-2 How reproducible: Always Steps to Reproduce: 1.run sensors-detect 2.answer "YES" to question "Do you want to scan the ISA bus?" 3. Actual Results: multiple errors on line 963, sensor chip not detected Expected Results: ITE8705 chip detected. Additional info: This worked on Limbo2.
Created attachment 71664 [details] script of sensors-detect run
The same happened in the case of my PR440FX based dual Pentium Pro system. The hardware sensor is some LM78 device. "sensors-detect" fails to detect the latter whereas this worked at least for Red Hat Linux 7.2 and 7.3. However, inserting the required modules (the same as in the past) by hand is possible (i2c-isa, lm78). The "sensors" command itself works properly then. It is thus solely a problem of "sensors-detect". The kernel support is functional.
There is a work around "patch" to the perl code that seems to fix things; however, it still begs the question of what changed to cause the actual problem. The file in question is called "sensors-detect" (located in the prog/detect subdirectory of the lm_sensors source tree). Here is a cvs diff from the lm_sensors cvs tree: 1075c1075 < my $towrite = pack "C", $_[1]; --- > my $towrite = pack "C", ($_[1] & 0xff); Note, your line number may vary. 1075 is based on the cvs tree for lm_sensors which I pulled (I have an a7v333 mobo that required the latest code). For null beta 3, the line number is 1068... Because the "broken" version is present in the lm_sensors cvs tree, I'm going to speculate that the problem may have to do with perl, not the script. The value that the "pack" function is complaining about is 0xFFFFFF80. I'm guessing that it didn't use to be sign extended and now it is ?!? Hope this helps...
Identical error happens in clean install of RHL8.0 (Psyche)
I've updated to latest upstream version 2.6.5, but that still contained that bug, so i fixed it in the latest rawhide build which is based on 2.6.5, too. Read ya, Phil