[lm-sensors] Patch: Kernel 2.6 and multiple buses

[lm-sensors] Patch: Kernel 2.6 and multiple buses

[Karsten Petersen]

[CC on answers please, I am not on the list.]

Hi,

during the last couple of hours I traced down some lm_sensors problems 
that occured with a Quad Opteron on Tyan 4882 running a kernel 2.6 distro.

My main problem is easily describable as:  Although there was a good 
looking sensors.conf, its options were not used with all chips.  Those 
chips with chip-lines like "bla-*" were ok, but those with lines like 
"bla-i2c-3-*" just showed default labels.

One first problem was, that the "bus" line in sensors.conf needs to have 
another value than when running kernel 2.4 on the same machine.
With kernel 2.4 its like this:
    bus "i2c-4" "SMBus 8111 adapter (CPU3)" "Non-I2C SMBus adapter"
But with kernel 2.6, it must be like this:
    bus "i2c-4" "SMBus 8111 adapter (CPU3)" "Unavailable from sysfs"
It seems to me, that the third argument is redundant these days, so it 
could probably be dropped or made optional.  It took me some time to 
find out about this problem, because the comparison in lib/data.c:233 is 
not helpful at all.  :-/

But this did not solve my problem, more sensor chips showed usefull 
labels but not all.  After a lot of printf debugging it became clear, 
that the sensors_substitute_chip function in lib/data.c assigns wrong 
bus numbers to the configured chips.  This is because the busses in the 
sensors_config_busses array are _not_ sorted, so 
sensors_config_busses[j] does not need to be the bus with id "j".  But 
the function thinks, that this is the case.  It probably was with kernel 
2.4, but not with the kernel 2.6.9 (+lot of patches) I am running.
The attached patch corrects this behavior, it uses the bus id from the 
entry sensors_config_busses[j] instead of "j".

With the patch attached to lm_sensors-2.9.1 and the changes to 
sensors.conf noted above, I can now see correctly labeled output from 
all sensors.

Best wishes
Karsten
-- 
HPC System Engineer

Tel.: +49 3722 528 43
Fax:  +49 3722 528 15
E-Mail: karsten.petersen@megware.com

MEGWARE Computer GmbH
Vertrieb und Service
Nordstra?e 19
09247 Chemnitz/R?hrsdorf
Germany
http://www.megware.com
-------------- next part --------------
diff -urNP lm_sensors-2.9.1-vanilla/lib/data.c lm_sensors-2.9.1/lib/data.c
--- lm_sensors-2.9.1-vanilla/lib/data.c	2004-05-16 16:25:20.000000000 +0200
+++ lm_sensors-2.9.1/lib/data.c	2005-09-09 11:19:49.388603409 +0200
@@ -230,8 +230,10 @@
     if (!strcmp(sensors_config_busses[i].adapter,
                 sensors_proc_bus[j].adapter) &&
         !strcmp(sensors_config_busses[i].algorithm,
-                sensors_proc_bus[j].algorithm)) 
-      break;
+                sensors_proc_bus[j].algorithm)) {
+      name->bus = sensors_proc_bus[j].number;
+      return 0;
+    }
   }
 
   /* Well, if we did not find anything, j = sensors_proc_bus_count; so if

[lm-sensors] Patch: Kernel 2.6 and multiple buses

[Jean Delvare]

Hi Karsten,

On 2005-09-09, Karsten Petersen wrote:

> My main problem is easily describable as:  Although there was a good 
> looking sensors.conf, its options were not used with all chips.  Those 
> chips with chip-lines like "bla-*" were ok, but those with lines like 
> "bla-i2c-3-*" just showed default labels.

Yes, this is a known problem with Linus 2.6.

> One first problem was, that the "bus" line in sensors.conf needs to have 
> another value than when running kernel 2.4 on the same machine.
> With kernel 2.4 its like this:
>    bus "i2c-4" "SMBus 8111 adapter (CPU3)" "Non-I2C SMBus adapter"
> But with kernel 2.6, it must be like this:
>    bus "i2c-4" "SMBus 8111 adapter (CPU3)" "Unavailable from sysfs"
> It seems to me, that the third argument is redundant these days, so it 
> could probably be dropped or made optional.  It took me some time to 
> find out about this problem, because the comparison in lib/data.c:233 is 
> not helpful at all.  :-/

Correct, that explains a part of the problem. Thanks for pointing it out.
We should probably drop the algorithm test completely (and make it
optional in the configuration file as you suggested, but I don't know
how do to this myself.) That algorithm name was given way too much
importance in the early days of lm_sensors, I believe it should never
have been handled by libsensors in the first place. Algorithms are
implementation details users don't care about.

> But this did not solve my problem, more sensor chips showed usefull 
> labels but not all.  After a lot of printf debugging it became clear, 
> that the sensors_substitute_chip function in lib/data.c assigns wrong 
> bus numbers to the configured chips.  This is because the busses in the 
> sensors_config_busses array are _not_ sorted, so 
> sensors_config_busses[j] does not need to be the bus with id "j".  But 
> the function thinks, that this is the case.  It probably was with kernel 
> 2.4, but not with the kernel 2.6.9 (+lot of patches) I am running.
> The attached patch corrects this behavior, it uses the bus id from the 
> entry sensors_config_busses[j] instead of "j".

Thanks a lot for this patch. I had been investigating this bug some times
ago but could never figure out what the problem was. It's really great
that you did succeed in finding the reason. I know it'll make a few
other users happy too.

Thanks again,
--
Jean Delvare

[lm-sensors] Patch: Kernel 2.6 and multiple buses

[Jean Delvare]

Hi again Karsten,

Quoting myself:
> Thanks a lot for this patch. I had been investigating this bug some
> times ago but could never figure out what the problem was. It's really
> great that you did succeed in finding the reason. I know it'll make a
> few other users happy too.

OK, I committed your patch, and also removed the algorithm name
comparison from the bus match test. Additionally, I dropped some
algorithm stuff from i2cbusses.c (which affects i2cset, i2cdump and
i2cdetect), sensors-detect and sensord, so that people stop wondering
about "unavailable algorithm name" messages.

I would appreciate if you could give a try to lm_sensors CVS and confirm
that it still works OK for you.

Thanks again for your contribution,
-- 
Jean Delvare