[lm-sensors] Some questions from first user

[lm-sensors] Some questions from first user

[Martin Herrman]

All,

my apologies if I bother you with simple noob questions in this mail.
On the other hand, if so they should be easy to answer :-)

My mainboard is a Gigabyte GA-Z68MX-UD2H-B3 which has a iTE IT8728 and
core i5 2500T (sandy bridge).

Unfortunately this board is not (yet :-)) on the list yet:

http://lm-sensors.org/wiki/Configurations/Gigabyte

So I'm trying to understand and optimize the output of sensors using a
file in /etc/sensors.d/

My questions:
1. coretemp outputs 5 temperatures. The last 4 are the cores, but what
is the value of the first one? (my guess: the temperature of the
highest core)

2. coretemp temperatures have (according to sensors -u) a _max, _crit
and _crit_alarm. How are these values determined? Does lm_sensors have
a database of existing cpu's and their max temperature specifications?

3. (follow-up on Q2) what is the difference between _max and _crit?
What happens when each of them is reached? What is the role of
_crit_alarm and how will the alarm be noticed?

4. (follow-up on Q3) how can I change the values for _max and _crit? I
tried 'set temp1_max 60' but that doesn't work. (sensors -s complains)

5. what is the difference between fan1_alarm and fan1_beep?

6. (follow-up on Q5) how do I set fan1_alarm? set fan1_alarm 1 doesn't
work. (sensors -s complains)

7. it8728 reports 3 different temps. When CPU is at full load, one of
them increases, but the value is much lower than the one reported by
coretemp (about 10 degrees lower). sensors outputs that it is Intel
PECI. According to the explanation on Wikipedia
(http://en.wikipedia.org/wiki/Platform_Environment_Control_Interface)
the temperature should be negative and increase towards 0 when cpu
temperature rises. Why does sensors show different values?

8. it8728 shows another two temps. Likely one case temp and the other
one the south bridge? How can I find out?

9. (from FAQ) "Do you have a database of sensors.conf entries for
specific boards?
No. Good idea though. If you would like to set one up on your website
send us mail and we will set up a link to it."
Why hasn't this been setup yet? Some sort of a database is at the
wiki, but doesn't contain many boards. Is any help still appreciated?
Is it just a table of manufacturer, type, sensors.conf file? (and
maybe some user registrations and comments by registered users?)

Thanks in advance for your help!

Martin

P.S. if answers can be found somewhere.. please let me know where to
find the documentation!

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Some questions from first user

[Jean Delvare]

Hi Martin,

On Wed, 8 Jan 2014 21:54:20 +0100, Martin Herrman wrote:
> my apologies if I bother you with simple noob questions in this mail.
> On the other hand, if so they should be easy to answer :-)
> 
> My mainboard is a Gigabyte GA-Z68MX-UD2H-B3 which has a iTE IT8728 and
> core i5 2500T (sandy bridge).
> 
> Unfortunately this board is not (yet :-)) on the list yet:
> 
> http://lm-sensors.org/wiki/Configurations/Gigabyte
> 
> So I'm trying to understand and optimize the output of sensors using a
> file in /etc/sensors.d/
> 
> My questions:
> 1. coretemp outputs 5 temperatures. The last 4 are the cores, but what
> is the value of the first one? (my guess: the temperature of the
> highest core)

The first temperature reported by coretemp is the "CPU package
temperature". I can't remember if it's a separate sensor or just
computed by the hardware as the maximum of the core temperatures.

> 2. coretemp temperatures have (according to sensors -u) a _max, _crit
> and _crit_alarm. How are these values determined? Does lm_sensors have
> a database of existing cpu's and their max temperature specifications?

On recent Intel processors these values are read from the CPU itself.
On older processors the driver has heuristics to figure them out. It
may get them wrong in a few cases. Check the driver documentation for a
list of known limits for older processors.

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/hwmon/coretemp

With a Core i5 you should be on the safe side.

> 3. (follow-up on Q2) what is the difference between _max and _crit?
> What happens when each of them is reached? What is the role of
> _crit_alarm and how will the alarm be noticed?

For the coretemp driver, _max is the temperature at which point all
cooling options should be enabled at full throttle. _crit is the
temperature at which the CPU integrity is no longer guaranteed. You
don't want to reach that temperature, ever.

_crit_alarm is raised when the measured (_input) temperature goes above
the _crit limit. This is checked by polling as the coretemp driver
currently doesn't have a notification mechanism. libsensors doesn't
support such notifications anyway. This should be added but I don't
have the time for that.

> 4. (follow-up on Q3) how can I change the values for _max and _crit? I
> tried 'set temp1_max 60' but that doesn't work. (sensors -s complains)

These are read-only limits specific to your CPU model. You don't get to
change them, sorry.

> 5. what is the difference between fan1_alarm and fan1_beep?

fan1_alarm triggers when fan1_input goes below fan1_min. It is
read-only. fan1_beep is writable and tells whether the alarm triggering
will result in your system beeping or not. Note that your board must be
properly wired (i.e. beep output of the monitoring chip routed to the
on-board buzzer or PC speaker) for this to work, which is unfortunately
not always the case.

> 6. (follow-up on Q5) how do I set fan1_alarm? set fan1_alarm 1 doesn't
> work. (sensors -s complains)

You don't, this is a read-only value which gets set by the hardware by
comparing fan1_input with fan1_min. It is set and cleared by the
hardware. What were you trying to achieve by setting it to 1 manually?

> 7. it8728 reports 3 different temps. When CPU is at full load, one of
> them increases, but the value is much lower than the one reported by
> coretemp (about 10 degrees lower). sensors outputs that it is Intel
> PECI. According to the explanation on Wikipedia
> (http://en.wikipedia.org/wiki/Platform_Environment_Control_Interface)
> the temperature should be negative and increase towards 0 when cpu
> temperature rises. Why does sensors show different values?

PECI is the low level specification. Users wouldn't understand that
sensors returns negative, relative temperature values. So all drivers
supporting PECI compute the actual temperature based on the negative
PECI value and the base temperature (maximum temperature supported by
the component being monitored, the CPU in this case.) For some drivers
(such as it87) this is even done by the hardware itself. This assumes
that the base temperature is known and correct, which is unfortunately
not always the case. In the case of the IT8728F chip, the base
temperature should be set by the BIOS depending on your CPU model. The
fact that the values differ between coretemp and it87 suggests that the
BIOS and the coretemp driver disagree about the base temperature (which
matches temp1_crit for the coretemp driver.)

> 8. it8728 shows another two temps. Likely one case temp and the other
> one the south bridge? How can I find out?

Check what the BIOS says, it typically shows two temperatures so that
should tell you what temp2 is. Check if the motherboard documentation
mentions anything. Then experiment by yourself (see what makes each
temperature rise the most.) It is possible that the 3rd temperature is
just noise.

> 9. (from FAQ) "Do you have a database of sensors.conf entries for
> specific boards?
> No. Good idea though. If you would like to set one up on your website
> send us mail and we will set up a link to it."
> Why hasn't this been setup yet? Some sort of a database is at the
> wiki, but doesn't contain many boards. Is any help still appreciated?
> Is it just a table of manufacturer, type, sensors.conf file? (and
> maybe some user registrations and comments by registered users?)

It has not been setup because nobody took the time and energy to do so.
Yes, it's "only" a set of configuration files indexed by board
manufacturer/model. But you need to store them somewhere in a safe way,
provide a way to search and retrieve them, provide a way to add and
amend them (with protection from spam or any form of abuse.) You are
welcome to help, but no, this isn't a trivial task.

> P.S. if answers can be found somewhere.. please let me know where to
> find the documentation!

Some parts of http://www.lm-sensors.org/wiki/Documentation are worth a
read, but it did not contain an answer to all your questions above.

-- 
Jean Delvare
http://khali.linux-fr.org/wishlist.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Some questions from first user

[Martin Herrman]

2014/1/9 Jean Delvare <khali@linux-fr.org>
>
> Hi Martin,

Hi Jean,

thanks for your extensive reply!

> > My questions:
> > 1. coretemp outputs 5 temperatures. The last 4 are the cores, but what
> > is the value of the first one? (my guess: the temperature of the
> > highest core)
>
> The first temperature reported by coretemp is the "CPU package
> temperature". I can't remember if it's a separate sensor or just
> computed by the hardware as the maximum of the core temperatures.

Check!

> > 2. coretemp temperatures have (according to sensors -u) a _max, _crit
> > and _crit_alarm. How are these values determined? Does lm_sensors have
> > a database of existing cpu's and their max temperature specifications?
>
> On recent Intel processors these values are read from the CPU itself.
> On older processors the driver has heuristics to figure them out. It
> may get them wrong in a few cases. Check the driver documentation for a
> list of known limits for older processors.
>
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/hwmon/coretemp
>
> With a Core i5 you should be on the safe side.

Check!

> > 3. (follow-up on Q2) what is the difference between _max and _crit?
> > What happens when each of them is reached? What is the role of
> > _crit_alarm and how will the alarm be noticed?
>
> For the coretemp driver, _max is the temperature at which point all
> cooling options should be enabled at full throttle. _crit is the
> temperature at which the CPU integrity is no longer guaranteed. You
> don't want to reach that temperature, ever.
>
> _crit_alarm is raised when the measured (_input) temperature goes above
> the _crit limit. This is checked by polling as the coretemp driver
> currently doesn't have a notification mechanism. libsensors doesn't
> support such notifications anyway. This should be added but I don't
> have the time for that.

Check!

> > 4. (follow-up on Q3) how can I change the values for _max and _crit? I
> > tried 'set temp1_max 60' but that doesn't work. (sensors -s complains)
>
> These are read-only limits specific to your CPU model. You don't get to
> change them, sorry.

Clear :-)

> > 5. what is the difference between fan1_alarm and fan1_beep?
>
> fan1_alarm triggers when fan1_input goes below fan1_min. It is
> read-only. fan1_beep is writable and tells whether the alarm triggering
> will result in your system beeping or not. Note that your board must be
> properly wired (i.e. beep output of the monitoring chip routed to the
> on-board buzzer or PC speaker) for this to work, which is unfortunately
> not always the case.

Check! (I tested my board, it doesn't beep..)

> > 6. (follow-up on Q5) how do I set fan1_alarm? set fan1_alarm 1 doesn't
> > work. (sensors -s complains)
>
> You don't, this is a read-only value which gets set by the hardware by
> comparing fan1_input with fan1_min. It is set and cleared by the
> hardware. What were you trying to achieve by setting it to 1 manually?

I was expecting that I could enable/disable a notification (e.g. a
beep from the PC speaker), but your explanation makes more sense (from
the it8728 engineer perspective). Clear!

> > 7. it8728 reports 3 different temps. When CPU is at full load, one of
> > them increases, but the value is much lower than the one reported by
> > coretemp (about 10 degrees lower). sensors outputs that it is Intel
> > PECI. According to the explanation on Wikipedia
> > (http://en.wikipedia.org/wiki/Platform_Environment_Control_Interface)
> > the temperature should be negative and increase towards 0 when cpu
> > temperature rises. Why does sensors show different values?
>
> PECI is the low level specification. Users wouldn't understand that
> sensors returns negative, relative temperature values. So all drivers
> supporting PECI compute the actual temperature based on the negative
> PECI value and the base temperature (maximum temperature supported by
> the component being monitored, the CPU in this case.) For some drivers
> (such as it87) this is even done by the hardware itself. This assumes
> that the base temperature is known and correct, which is unfortunately
> not always the case. In the case of the IT8728F chip, the base
> temperature should be set by the BIOS depending on your CPU model. The
> fact that the values differ between coretemp and it87 suggests that the
> BIOS and the coretemp driver disagree about the base temperature (which
> matches temp1_crit for the coretemp driver.)

Clear again. coretemp _crit temperature is correct, so I have to
adjust the IT8728F cpu temperature with 10 degrees:

compute temp3 @+10,@+10

(Note: I wonder if this is influenced by my BIOS settings, which
allows me to change the temperature for CPU warning.)

> > 8. it8728 shows another two temps. Likely one case temp and the other
> > one the south bridge? How can I find out?
>
> Check what the BIOS says, it typically shows two temperatures so that
> should tell you what temp2 is. Check if the motherboard documentation
> mentions anything. Then experiment by yourself (see what makes each
> temperature rise the most.) It is possible that the 3rd temperature is
> just noise.

Ok, a simple cpu load test showed that temp3 is the cpu temp. When I
compare with the bios, I believe that temp1 is the system/case temp.
In that case temp2 is the noise, but the difference between temp1 and
temp2 is only about 3-4 degrees.

The user manual of my motherboard doesn't have much information about
the temperature sensors.

> > 9. (from FAQ) "Do you have a database of sensors.conf entries for
> > specific boards?
> > No. Good idea though. If you would like to set one up on your website
> > send us mail and we will set up a link to it."
> > Why hasn't this been setup yet? Some sort of a database is at the
> > wiki, but doesn't contain many boards. Is any help still appreciated?
> > Is it just a table of manufacturer, type, sensors.conf file? (and
> > maybe some user registrations and comments by registered users?)
>
> It has not been setup because nobody took the time and energy to do so.
> Yes, it's "only" a set of configuration files indexed by board
> manufacturer/model. But you need to store them somewhere in a safe way,
> provide a way to search and retrieve them, provide a way to add and
> amend them (with protection from spam or any form of abuse.) You are
> welcome to help, but no, this isn't a trivial task.

I started a new thread on this one.

> > P.S. if answers can be found somewhere.. please let me know where to
> > find the documentation!
>
> Some parts of http://www.lm-sensors.org/wiki/Documentation are worth a
> read, but it did not contain an answer to all your questions above.

Pfhew! :-)

I currently believe that my last two questions are:

10. How are temp1_min and temp1_max determined for the it8728 reportes
temperatures?

11. What is temp1_type and temp1_offset?

Thanks in advance again!

Martin

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Some questions from first user

[Jean Delvare]

On Thu, 16 Jan 2014 22:24:20 +0100, Martin Herrman wrote:
> 2014/1/9 Jean Delvare <khali@linux-fr.org>
> > PECI is the low level specification. Users wouldn't understand that
> > sensors returns negative, relative temperature values. So all drivers
> > supporting PECI compute the actual temperature based on the negative
> > PECI value and the base temperature (maximum temperature supported by
> > the component being monitored, the CPU in this case.) For some drivers
> > (such as it87) this is even done by the hardware itself. This assumes
> > that the base temperature is known and correct, which is unfortunately
> > not always the case. In the case of the IT8728F chip, the base
> > temperature should be set by the BIOS depending on your CPU model. The
> > fact that the values differ between coretemp and it87 suggests that the
> > BIOS and the coretemp driver disagree about the base temperature (which
> > matches temp1_crit for the coretemp driver.)
> 
> Clear again. coretemp _crit temperature is correct, so I have to
> adjust the IT8728F cpu temperature with 10 degrees:
> 
> compute temp3 @+10,@+10

Preferred way of doing this when the hardware supports it (and the
IT8728F does) is:

    set temp3_offset 10

That being said I am not 100% positive that this works when the
temperature sensor type is PECI. You'll have to try it out and see.

> (Note: I wonder if this is influenced by my BIOS settings, which
> allows me to change the temperature for CPU warning.)

It should indeed be. It's easy enough to try.

> > Check what the BIOS says, it typically shows two temperatures so that
> > should tell you what temp2 is. Check if the motherboard documentation
> > mentions anything. Then experiment by yourself (see what makes each
> > temperature rise the most.) It is possible that the 3rd temperature is
> > just noise.
> 
> Ok, a simple cpu load test showed that temp3 is the cpu temp. When I
> compare with the bios, I believe that temp1 is the system/case temp.
> In that case temp2 is the noise, but the difference between temp1 and
> temp2 is only about 3-4 degrees.
> 
> The user manual of my motherboard doesn't have much information about
> the temperature sensors.

It is possible that the board actually has two board sensors, even if
the BIOS doesn't report both. As long as the values make sense and move
in a realistic way, there is no reason to discard them.

> I currently believe that my last two questions are:
> 
> 10. How are temp1_min and temp1_max determined for the it8728 reportes
> temperatures?

They are arbitrary limits that can be set by the BIOS or the user. Min
isn't so useful unless you live in Alaska or leave you system outside
in winter. Max is more useful but only if some action is triggered by
the alarm flag raising, either in the hardware or by software polling
for the alarm flag.

> 11. What is temp1_type and temp1_offset?

The sensor type (thermistor, thermal diode or digital aka PECI) and an
offset that can be added by the hardware automatically, respectively.

You normally don't have to change the sensor type as it should be set
right by the BIOS. The type OTOH gives you a hint on what is what:
board sensors are typically thermistors while CPU sensors are typically
thermal diodes or PECI.

Setting the offset attribute is equivalent to a simple compute formula,
as stated above, and is more efficient as it is done by the hardware.
It is also more convenient if you start playing with temperature-based
fan speed control.

Hope that helps,
-- 
Jean Delvare
http://jdelvare.nerim.net/wishlist.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Some questions from first user

[Martin Herrman]

2014/1/16 Jean Delvare <khali@linux-fr.org>:

Hi Jean,

>> compute temp3 @+10,@+10
>
> Preferred way of doing this when the hardware supports it (and the
> IT8728F does) is:
>
>     set temp3_offset 10
>
> That being said I am not 100% positive that this works when the
> temperature sensor type is PECI. You'll have to try it out and see.

I have did some testing, but I'm not sure yet what to report. I don't
have a clear picture with repeatable results yet.

Offset values are by default not 0, does lm_sensors init script reset
offset values to default when removed from sensors.conf?, should I
compile sensor drivers as modules? (currently they are in the kernel,
so my init script fails when it tries to reload the modules),
sometimes I get negative values for _input when I switch from compute
to offset statement, why does compute +10 add 20 to reported values?

Actually, I think my most important question is: how does the compute
statement work?

>> (Note: I wonder if this is influenced by my BIOS settings, which
>> allows me to change the temperature for CPU warning.)
>
> It should indeed be. It's easy enough to try.

Answer after some testing: bios configuration defines the temp3_max value.

> It is possible that the board actually has two board sensors, even if
> the BIOS doesn't report both. As long as the values make sense and move
> in a realistic way, there is no reason to discard them.

I have put high load on both CPU and GPU, which automatically
increases case temp. Both temp1 and temp2 increase equally. So I
assume you are right, the board has 2 sensors but the bios only
reports 1.

>> I currently believe that my last two questions are:
>>
>> 10. How are temp1_min and temp1_max determined for the it8728 reportes
>> temperatures?
>
> They are arbitrary limits that can be set by the BIOS or the user. Min
> isn't so useful unless you live in Alaska or leave you system outside
> in winter. Max is more useful but only if some action is triggered by
> the alarm flag raising, either in the hardware or by software polling
> for the alarm flag.

As expected, thanks!

>> 11. What is temp1_type and temp1_offset?
>
> The sensor type (thermistor, thermal diode or digital aka PECI) and an
> offset that can be added by the hardware automatically, respectively.
>
> You normally don't have to change the sensor type as it should be set
> right by the BIOS. The type OTOH gives you a hint on what is what:
> board sensors are typically thermistors while CPU sensors are typically
> thermal diodes or PECI.
>
> Setting the offset attribute is equivalent to a simple compute formula,
> as stated above, and is more efficient as it is done by the hardware.
> It is also more convenient if you start playing with temperature-based
> fan speed control.

Thanks, this helps!

So I only have to figure out how to get the values right for temp3 and
the interaction between offset and compute values :-)

Regards,

Martin

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Some questions from first user

[Jean Delvare]

Hi Martin,

On Sat, 18 Jan 2014 11:06:52 +0100, Martin Herrman wrote:
> 2014/1/16 Jean Delvare <khali@linux-fr.org>:
> >> compute temp3 @+10,@+10
> >
> > Preferred way of doing this when the hardware supports it (and the
> > IT8728F does) is:
> >
> >     set temp3_offset 10
> >
> > That being said I am not 100% positive that this works when the
> > temperature sensor type is PECI. You'll have to try it out and see.
> 
> I have did some testing, but I'm not sure yet what to report. I don't
> have a clear picture with repeatable results yet.
> 
> Offset values are by default not 0,

It is possible that your BIOS does the right thing and presets the
offsets as appropriate.

> does lm_sensors init script reset
> offset values to default when removed from sensors.conf?,

The lm_sensors init script will typically run "sensors -s" when
starting the service. When stopping the service, it shouldn't change any
setting. "sensors -s" applies all relevant "set" statements in your
sensors.conf configuration files, taking offsets and compute statements
into account.

> should I
> compile sensor drivers as modules? (currently they are in the kernel,
> so my init script fails when it tries to reload the modules),

The init script (and sensors-detect until very recently) assumes that
every driver is a module, so this isn't surprising. Some work is still
needed to ensure a smooth user experience with monolithic kernels. I'm
fixing things slowly in this area, but this isn't a priority.

> sometimes I get negative values for _input when I switch from compute
> to offset statement, why does compute +10 add 20 to reported values?

It shouldn't. This might be an unexpected effect of conflicting set
statements, or offset and compute formula being applied to the same
temperature input, or a bug somewhere. I can't really say without more
details from you: complete configuration section from your chip
from /etc/sensors3.conf and any relevant configuration file
under /etc/sensors.d, output of "sensors", output of "sensors
-c /dev/null", output of "sensors -u".

> Actually, I think my most important question is: how does the compute
> statement work?

Originally the driver gets the raw temperature value reported by the
sensor. Then it applies the offset and presents the result to
user-space (through a sysfs attribute.) Libsensors gets that value and
applies the first half of the compute formula for this channel, and
presents the result to the user.

The second half of the compute formula should always be the inverse
function of the first half, and is applied by libsensors to the
matching set statements.

Let's take an example. You have a temperature sensor (temp1) which
reports a raw value of 50°C. If temp1_offset is defined as +5°C, the
driver will report temp1_input as 55°C.

If you happen to have a compute formula for temp1 such as:

    compute temp1 @+10, @-10

then "sensors" will display a temp1 input value of 65°C. The compute
formula applies to the limits as well, so if for example the driver
reported the min limit as 10°C and the max limit as 60°C, "sensors"
will show 20°C and 70°C as the limits instead.

In practice you typically use the offset attribute _instead of_ the
compute formula (assuming you only have to apply an offset), because it
is more efficient.

-- 
Jean Delvare
http://jdelvare.nerim.net/wishlist.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Some questions from first user

[Martin Herrman]

2014/1/18 Jean Delvare <khali@linux-fr.org>:
> Hi Martin,

Hi Jean,

>> Offset values are by default not 0,
>
> It is possible that your BIOS does the right thing and presets the
> offsets as appropriate.

That's right. Default it sets it to 72, so to increase with 10 I have
to set to 82.

>> does lm_sensors init script reset
>> offset values to default when removed from sensors.conf?,
>
> The lm_sensors init script will typically run "sensors -s" when
> starting the service. When stopping the service, it shouldn't change any
> setting. "sensors -s" applies all relevant "set" statements in your
> sensors.conf configuration files, taking offsets and compute statements
> into account.

I checked the gentoo init script and yes, it also does sensors -s.

However, it doesn't reset values to the BIOS settings (I guess it
cannot retrieve the BIOS settings). So when removing a setting in
sensors.conf and using the init script, will not reset the removed
setting to BIOS value.

>> should I
>> compile sensor drivers as modules? (currently they are in the kernel,
>> so my init script fails when it tries to reload the modules),
>
> The init script (and sensors-detect until very recently) assumes that
> every driver is a module, so this isn't surprising. Some work is still
> needed to ensure a smooth user experience with monolithic kernels. I'm
> fixing things slowly in this area, but this isn't a priority.

Although it doesn't change anything (except that the init script
doesn't warn anymore) I have recompiled the kernel to use modules.

>> sometimes I get negative values for _input when I switch from compute
>> to offset statement, why does compute +10 add 20 to reported values?
>
> It shouldn't. This might be an unexpected effect of conflicting set
> statements, or offset and compute formula being applied to the same
> temperature input, or a bug somewhere. I can't really say without more
> details from you: complete configuration section from your chip
> from /etc/sensors3.conf and any relevant configuration file
> under /etc/sensors.d, output of "sensors", output of "sensors
> -c /dev/null", output of "sensors -u".

I can explain negative values: BIOS sets offset to 72, so when set to
10 it will decrease by 62 instead of adding 10 :-)

>> Actually, I think my most important question is: how does the compute
>> statement work?
>
> Originally the driver gets the raw temperature value reported by the
> sensor. Then it applies the offset and presents the result to
> user-space (through a sysfs attribute.) Libsensors gets that value and
> applies the first half of the compute formula for this channel, and
> presents the result to the user.
>
> The second half of the compute formula should always be the inverse
> function of the first half, and is applied by libsensors to the
> matching set statements.
>
> Let's take an example. You have a temperature sensor (temp1) which
> reports a raw value of 50°C. If temp1_offset is defined as +5°C, the
> driver will report temp1_input as 55°C.
>
> If you happen to have a compute formula for temp1 such as:
>
>     compute temp1 @+10, @-10
>
> then "sensors" will display a temp1 input value of 65°C. The compute
> formula applies to the limits as well, so if for example the driver
> reported the min limit as 10°C and the max limit as 60°C, "sensors"
> will show 20°C and 70°C as the limits instead.
>
> In practice you typically use the offset attribute _instead of_ the
> compute formula (assuming you only have to apply an offset), because it
> is more efficient.

Ah! Finally.. it all makes sense now :-)

I believe that I have a configuration file that is worth to be put on
the trac/wiki. Just one issue.. where can I register for trac access?

Regards,

Martin

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Some questions from first user

[Jean Delvare]

Hi Martin,

On Sun, 19 Jan 2014 14:32:37 +0100, Martin Herrman wrote:
> However, it doesn't reset values to the BIOS settings (I guess it
> cannot retrieve the BIOS settings). So when removing a setting in
> sensors.conf and using the init script, will not reset the removed
> setting to BIOS value.

Indeed BIOS values aren't stored anywhere so the only way to go back to
them is to cold boot the machine.

> (...)
> I can explain negative values: BIOS sets offset to 72, so when set to
> 10 it will decrease by 62 instead of adding 10 :-)

72 is an unusually high offset. It might have to do with PECI sensor
type where values are reported relatively to a limit. Different
monitoring chips handle this case differently.

> (...)
> I believe that I have a configuration file that is worth to be put on
> the trac/wiki. Just one issue.. where can I register for trac access?

You can't, we have disabled user self-registration due to the high
amount of spam. Just send your file to the list and I'll add it to the
wiki myself.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Some questions from first user

[Guenter Roeck]

On 01/19/2014 05:51 AM, Jean Delvare wrote:
> Hi Martin,
>
> On Sun, 19 Jan 2014 14:32:37 +0100, Martin Herrman wrote:
>> However, it doesn't reset values to the BIOS settings (I guess it
>> cannot retrieve the BIOS settings). So when removing a setting in
>> sensors.conf and using the init script, will not reset the removed
>> setting to BIOS value.
>
> Indeed BIOS values aren't stored anywhere so the only way to go back to
> them is to cold boot the machine.
>
>> (...)
>> I can explain negative values: BIOS sets offset to 72, so when set to
>> 10 it will decrease by 62 instead of adding 10 :-)
>
> 72 is an unusually high offset. It might have to do with PECI sensor
> type where values are reported relatively to a limit. Different
> monitoring chips handle this case differently.
>

Yes, that is usually what happens with PECI. The 'offset' is really
the maximum temperature, since PECI delivers the difference to that
temperature.

Guenter


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Some questions from first user

[Martin Herrman]

[-- Attachment #1: Type: text/plain, Size: 281 bytes --]

2014/1/19 Jean Delvare <khali@linux-fr.org>:

Hi Jean,

> You can't, we have disabled user self-registration due to the high
> amount of spam. Just send your file to the list and I'll add it to the
> wiki myself.

attached is my file, I hope it is good enough :-)

Thanks,

Martin

[-- Attachment #2: gigabyte_ga-z68mx-ud2h-b3.conf --]
[-- Type: application/octet-stream, Size: 3399 bytes --]

# LM-Sensors config file for Gigabyte GA-Z38MX-UD2H-B3 mainboard with 
# an Intel i5 Sandy Bridge quad core CPU installed.

# Tested with kernel 3.10.x and lm-sensors 3.3.x on Gentoo Linux.

# Created by Martin Herrman <martin@herrman.nl> with help from Jean Delvare
# from the lm-sensors mailinglist.

# Questions, comments or additions? Please share on the lm-sensors mailinglist.
# More info at http://www.lm-sensors.org/wiki/FeedbackAndSupport

# Hint: Use sensors -u to list all variables.

chip "coretemp-*"
# chip coretemp measures cpu temperatures from i5 CPU temperature sensor
# _max, _crit and _crit_alarm are read from the cpu itself
# when temp is at _max, all cooling options must be at full throttle
# when temp is at _crit, cpu starts to fail
# _crit_alarm is automatically set by hardware when _input is at or above _crit
# libsensors currently doesn't support the trigger of a notification system
label temp1 "CPU Package temp"
label temp2 "Core 0"
label temp3 "Core 1"
label temp4 "Core 2"
label temp5 "Core 3"

# IT8728F is on the mainboard and provides voltages and cpu/case fan speed
chip "it8728-*"

# I'm not interested in voltages, sorry.
ignore in0
ignore in1
ignore in2
ignore in3
ignore in4
ignore in5
ignore in6
ignore in7
ignore in8

# scythe kozuti min = 800
# output of sensors will show ALARM (_alarm is set to 1) when actual fan 
# speed (_input) is below set minimum (_min). If _beep is set to 1, and
# the motherboard is wired between the temperature sensor and the
# PC speaker, the PC speaker will start beeping.
# Unfortunately Gigabyte GA-Z68MX-UD2H-B3 is not properly wired.
label fan1 "CPU fan"
set fan1_min 800 
set fan1_beep 1

# I don't have a case fan installed via PWM
ignore fan2
#label fan2 "Case fan"
#set fan2_min 1000
#set fan2_beep 1

# Motherboard temps
 
# Note: tempX_type indicates the type of sensor and is set by the BIOS

# When comparing temp1 and temp2 with BIOS value, temp1 seems to be similar to BIOS system temperature.
# temp2 increases like temp1 does, so I assume that it is another case temp but not shown in BIOS.
label temp1 "Case temp (shown in BIOS)"
label temp2 "Case temp (hidden in BIOS)"

# The reported values seem to be correct. No need to add offset or compute. 

# Let's set some real world values for min and max
set temp1_min 25
set temp1_max 50
set temp2_min 25
set temp2_max 50

# Let's alarm when temperatures are outside range
set temp1_beep 1
set temp2_beep 1

# temp3 increases when cpu high load, so assuming this is CPU temperature.
label temp3 "CPU temp"

# Note: PECI value is negative value relative to _crit, but driver calculates
# to real value.

# Adding 10 to correct wrong BIOS values.
# Change offset is more efficient than computing new value, because offset is done in hardware.
# Note: using compute also increases min and max values. You will need to set the min and max values below.
# Note: offset default value is 72, so add 10 makes 82.
#compute temp3 @+10,@-10
set temp3_offset 82

# In BIOS it is possible to set CPU warning temperature, but this does not influence
# temp3_input. However, it does change the temp3_max. My bios setting is at 60
# degrees. Coretemp defines maximum of 76. I want a warning at 60.
# _min, _max
set temp3_min 25
#set temp3_max 60

# Let's alarm when temperature is outside range
set temp3_beep 1

# ignore intrusion detection (case open?)
ignore intrusion0

[-- Attachment #3: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Some questions from first user

[Jean Delvare]

On Mon, 20 Jan 2014 11:07:15 +0100, Martin Herrman wrote:
> 2014/1/19 Jean Delvare <khali@linux-fr.org>:
> > You can't, we have disabled user self-registration due to the high
> > amount of spam. Just send your file to the list and I'll add it to the
> > wiki myself.
> 
> attached is my file, I hope it is good enough :-)

Added to the wiki as:
http://www.lm-sensors.org/wiki/Configurations/Gigabyte/Z38MX-UD2H-B3

I removed the "ignore" statements for in* and fan2: just because you
aren't interested doesn't mean other users won't be.

Thanks for your contribution.

-- 
Jean Delvare
http://jdelvare.nerim.net/wishlist.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors