Add support for sysfs attributes temp[1-*]_min_hyst (already
implemented by drivers adt7x10, lm77 and lm92) and
temp[1-*]_lcrit_hyst (no known users yet.)
While there is no longer a hard limit to the number of sensor of a
given type per chip, I feel a little uncomfortable having no limit at
all on the amount of memory we may try to allocate. Add an arbitrary
safety limit so that a design error or a bug in a hwmon driver can't
result into an insane memory allocation.
Make memory pre-allocation steps depend on the sensor type. Things like
voltages, temperatures or fans are typically plenty, however vid and
chassis intrusion are typically only a few, and there can only be one
beep_enable by design. This saves a small amount of temporary memory
for cheap.
max_subfeatures is computed the first time it is needed, we can do
exactly the same with FEATURE_SIZE. Introduce feature_size as a static
variable so that we don't have to recompute it again and again.
When gathering the attributes of each hwmon chip, libsensors uses a
temporary structure in memory to order and group all the attributes
into features. This temporary structure used to be a single array with
room for every possible attribute/subfeature. While simple, this
approach required to predefine a maximum number of per-type sensor
that could be handled.
In order to get rid of this arbitrary limit, which we hit and had to
raise three times already, I changed the temporary structure to an
array of dynamically allocated per-type subattribute arrays. This lets
us not allocate any memory for types which aren't implemented by a
given chip, and more importantly, this lets us reallocate room for
more attributes of a given type as needed.
I decided to allocate chunks of 8 attributes at a time, as this seemed
a good compromise between two frequent reallocations and
over-provisioning. It could be tweaked if needed.
Icing on the cake, I benchmarked this change on two different systems
and it results in performance gains. The total heap usage as reported
by valgrind is down by 50% on average, with peak memory consumption
(as reported by valgrind's massif) also down by 43% on average. The
total instructions count (as reported by valgrind's callgrind) is down
by 11% on average, with measured execution time also down by a few
percents. Valgrind rocks, BTW.
I have some ideas to optimize the memory allocations further, but I do
not expect such a huge gain from them. They may not even improve peak
memory consumption as massif shows the peak is somewhere else now at
least in some cases.
Several kernel drivers have already moved their attributes from the
hardware device to the hwmon class device, and others will follow.
Teach fancontrol about this possibility and let it adjust the attribute
paths transparently.
With recent (>202) systemd release, syslog.target is no longer provided:
services are ensured they are started after logging socket is setup, so
journal will capture all syslog messages and will store them and forward
them to syslog implementation (if running).
Patch from Ville Skyttä.
Based on a report and an original patch from Jaromir Capik:
There's no vendor_id entry in the /proc/cpuinfo file in case of PPC64
systems and consequently the script returns 3 screens full of the
following errors:
Use of uninitialized value in string eq at /usr/sbin/sensors-detect
line 6444
Use of uninitialized value in string eq at /usr/sbin/sensors-detect
line 6459
Use of uninitialized value in string eq at /usr/sbin/sensors-detect
line 6473
sensors_get_adapter_name(). Paul Crawford asked questions about these
as he found the original documentation unclear. I'm including my
answers to his questions here, reformatted, so that other developers
can benefit from them too.
It is better to use option --auto for non-interactive runs of the
sensors-detect script than faking an input to get the default answers
to all questions.
/sys/module doesn't actually contain all built-in modules, only the
ones which have a version or at least one parameter. Better use file
modules.builtin which is generated since kernel 2.6.33, it is complete
and this will let us handle built-in modules properly.
Reported by Marc Ferland. Make DEVPATH and DEVNAME mandatory only when
using relative paths. Optionally support DEVNAME check when using
absolute paths.
Detection of the Dallas/Maxim DS1621, DS1625 and DS1631 chips is weak
and likely to result in false positive. There's no rationale for
keeping it in sensors-detect as these chips are not found in desktop
computer systems. So drop detection of these chips altogether.
When a given PWM output controls more than one fan,
fanactive_min is no longer a space-separated list of numbers, it will
also include items of the form "A+B". The tests in the rest of the
code do not expect that and choke with errors like:
/usr/sbin/pwmconfig: line 926: [: 538+799: integer expression expected
/usr/sbin/pwmconfig: line 952: [: 538+799: integer expression expected
As the only thing we really care about is whether any fan stops
completely when PWM is 0, we can simply record the minimum of the
lowest speed of all affected fans.
Detection threshold of 2/3 of the maximum speed is too low, some fans
will slow down to about that speed so controlled fans may be missed.
Use 3/4 as the threshold to avoid these false negatives.
Print the initial PWM values before letting the user change them. This
should be useful to better understand what happens next, and for user
support in general.
Patch from Jaromir Capik.
The device file /dev/port might be missing in some cases
and the sensors detection is terminated when the user
tries to detect sensors dependent on it's existence.
That's not correct -> it's not a reason for terminating
the detection.
/proc/modules so we will try to load it, even though it's already
available. It will succeed, however later attempts to remove the
driver will fail and such failures are reported at the end of the
script, which can be confusing.
So, use /sys/module instead of /proc/modules where available, as
built-in drivers are listed there too so we no longer attempt to load
already available drivers. As a consequence we also no longer attempt
to remove the drivers in question, thus clearing the error message.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@6114 7894878c-1315-0410-8ee3-d5d059ff63e0
Take multiplexers into account when looking up the parent device of
each I2C adapter. We don't bother with old kernels as they didn't have
support for multiplexers anyway.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@6085 7894878c-1315-0410-8ee3-d5d059ff63e0
Don't probe I2C buses on graphics cards by default. Their drivers will
typically instantiate the I2C slave devices themselves as needed, and
such probes have been occasionally reported to cause serious trouble.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@6084 7894878c-1315-0410-8ee3-d5d059ff63e0
On recent systems, extra configuration files can live in
/etc/ld.so.conf.d, so check this directory too, before warning.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@6045 7894878c-1315-0410-8ee3-d5d059ff63e0
attributes. These are defined in the standard sysfs interface for quite
some time, and at least three drivers (max6650, lm63 and applesmc)
implement them so we should support them.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@6029 7894878c-1315-0410-8ee3-d5d059ff63e0
There is no rationale for having separate functions, both are static
and called only once. do_features() is calling helper functions to get
values it doesn't use and passes to get_features() directly. Having a
single function is more efficient and allows for per-action
optimizations.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@6026 7894878c-1315-0410-8ee3-d5d059ff63e0
The leak in daemonize() is harmless, we're about to exit anyway. Fix
it still to make valgrind happy.
The leak in do_features() is real, as the function is called
periodically by the daemon, for all actions. If the intervals at set
low and the system has many sensors, the leak could be significant,
maybe 150 kB/day.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@6025 7894878c-1315-0410-8ee3-d5d059ff63e0
LM96080. It is functionally compatible with the LM80 but detection is
completely different.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@6018 7894878c-1315-0410-8ee3-d5d059ff63e0
Jean Delvare