On 22-06-08 09:28, Hans de Goede wrote:
This is an ABI breakage issue and an unfortunate one at that:
Rene Herman wrote:
On 2.6.26-rc and perhaps earlier, when I enable the ACPI Thermal Zone
support (CONFIG_ACPI_THERMAL) I see in dmesg:
Note, 2.6.25-rc7 works fine with it enabled.
ACPI: LNXTHERM:01 is registered as thermal_zone0
ACPI: Thermal Zone [THRM] (56 C)
My /sys/class/hwmon/hwmon0 (a W83782D chip) becomes hwmon1, there's a
new /sys/class/hwmon/hwmon0 and "sensors -s" craps out with:
# sensors -s
Can't access procfs/sysfs file
Kernel interface access error
For 2.6 kernels, make sure you have mounted sysfs and libsensors
was compiled with sysfs support!
# sensors --version
sensors version 2.10.6 with libsensors version 2.10.6
This is the slackware 12.1 (recent) standard version. What's wrong?
In case it's useful, my /etc/sensors.conf is at:
http://members.home.nl/rene.herman/sensors.conf
I'm pretty sure this caused by your lm_sensors using space being to old
to support the new thermalzone stuff. You need atleast 3.0.2 to support
the thermalzone driver.
I see. I was about to mark this up as Volkerding doing his usual "if it
has a lower version number it must be better" thing but in this case it
seems it's hwmon or ACPI which is to blame.
Firstly -- with CONFIG_ACPI_THERMAL selected my sensors work fine on
2.6.25-rc7 with the above 2.10.6 lm_sensors userspace. Now, with
2.6.26-rc (*) they do not as per above.
This is ABI breakage. I wouldn't care if my older lm_sensors userspace
couldn't handle the ACPI Thermal Zone, but I do care that even having it
breaks my other sensors; especially given the CONFIG_ACPI_THERMAL help
text which can not be read as recommending to disable it:
This driver adds support for ACPI thermal zones. Most mobile and
some desktop systems support ACPI thermal zones. It is HIGHLY
recommended that this option be enabled, as your processor(s)
may be damaged without it.
Now, I'm actually usally a big fan of not dragging around old gunk
forever, ABI be damned, but in this case this really won't do. 2.6.10 is
a recent maintenance release and I see for the new 3.0 branch:
http://www.lm-sensors.org/wiki/Download
===
Most third party monitoring applications do not yet work with the
library in this package. We are encouraging authors to port their
applications to the new library. We already have patches for xsensors
0.60, gkrellm-2.3.0, net-snmp-5.4.1 (configure with
--with-mib-modules="ucd-snmp/lmsensorsMib" --with-ldflags="-lsensors"),
xfce4-sensors-plugin-0.10.99.2, kdebase-3.5.8(ksysguard),
sensors-applet-1.8.1 and ksensors-0.7.3-fedora-14.tar.gz (upstream is
dead this tarbal contains a version with all Debian's changes + 2
patches from Fedora, including lm_sensors-3.x support).
===
So it seems we have here a change to the kernel requiring a userspace
basically noone is ready for and which at least the (again, recent)
slackware 12.1 doesn't ship as a result. This is ABI breakage of the
really bad kind.
If there's not just something I'm missing, could someone please get
Linus a patch ASAP making whatever breaks lm_sensors 2 optional,
disabled by default and with a help text that warns that enabling it
requires a new lm_sensors userspace?
I haven't seen other complaints about this and would've expected them so
it might ofcourse be possible that I'm just missing something and have a
very specific problem; if in that case someone could advice what it
might be -- please do.
But if not, .26 is around the corner and requiring libsensors-3.0 must
really not be.
(*) 2.6.26-rc7 at least. I actually noticed this early in the -rc stage
but had too many other breakage at that point to worry about this one. I
just disabled the ACPI Thermal Zone support and forgot about it upto
this point.
Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
