"No temperature information is available" although machine does have thermal sensors

This happens because we use acpi to get the thermal data, and this seems to work only for laptops.

A workaround is to use a custom graph to plot the desired output of the sensors command. Here is an example:

https://help.landscape.canonical.com/CustomGraphs/Examples#lm-sensors

That being said, we could probably fallback to lm-sensors if there is no temperature being reported by acpi.

One of the concerns I have is that the output of sensors is not always accurate and can be confusing, with names we have no idea what they represent, like temp1, temp2, etc.

In my laptop, for example, I have 16 values for "temp" alone when using the "ISA adapter", and two values for the "Virtual Device" adapter. I have no idea how we could decide programatically which values to use in the graph. What I usually do is pick the one that looks more reasonable, or agrees with what I see in the computer BIOS, and stick to that.

Just for completeness, here is the output I get on my laptop:

root@nsn2:~# sensors
acpitz-virtual-0
Adapter: Virtual device
temp1: +53.0°C (crit = +127.0°C)
temp2: +61.0°C (crit = +100.0°C)

thinkpad-isa-0000
Adapter: ISA adapter
fan1: 3045 RPM
temp1: +53.0°C
temp2: +45.0°C
temp3: +35.0°C
temp4: +63.0°C
temp5: +50.0°C
ERROR: Can't get value of subfeature temp6_input: Can't read
temp6: +0.0°C
temp7: +34.0°C
ERROR: Can't get value of subfeature temp8_input: Can't read
temp8: +0.0°C
temp9: +40.0°C
temp10: +47.0°C
temp11: +45.0°C
ERROR: Can't get value of subfeature temp12_input: Can't read
temp12: +0.0°C
ERROR: Can't get value of subfeature temp13_input: Can't read
temp13: +0.0°C
ERROR: Can't get value of subfeature temp14_input: Can't read
temp14: +0.0°C
ERROR: Can't get value of subfeature temp15_input: Can't read
temp15: +0.0°C
ERROR: Can't get value of subfeature temp16_input: Can't read
temp16: +0.0°C

On 23 November 2010 20:40, Andreas Hasenack <email address hidden> wrote:
> This happens because we use acpi to get the thermal data, and this seems
> to work only for laptops.
>
> A workaround is to use a custom graph to plot the desired output of the
> sensors command. Here is an example:
>
> https://help.landscape.canonical.com/CustomGraphs/Examples#lm-sensors
>
> That being said, we could probably fallback to lm-sensors if there is no
> temperature being reported by acpi.

... or, perhaps better, just use the abstraction across various
methods provided by libsensors? People might also want to graph hdd
temperatures?

> One of the concerns I have is that the output of sensors is not always
> accurate and can be confusing, with names we have no idea what they
> represent, like temp1, temp2, etc.

I agree, though this does seem to be a problem for acpi too?

> In my laptop, for example, I have 16 values for "temp" alone when using
> the "ISA adapter", and two values for the "Virtual Device" adapter. I
> have no idea how we could decide programatically which values to use in
> the graph. What I usually do is pick the one that looks more reasonable,
> or agrees with what I see in the computer BIOS, and stick to that.

Another problem, across all methods, is that some sensors seem stuck
at unreasonable values like 0 or 127C.

If I was going to programmatically reduce it to a single value, I
would probably take the maximum plausible value at any moment across
all sensors. Or do this per grouping, if we're getting any useful
grouping metadata: the hottest probe in the drives is currently: 46C;
the hottest probe in the cpu is 48C; etc.

For things like drives or other swappable devices, users might care
which particular drive is overheating; for cpu or motherboard
measurement it seems to me not to be very meaningful.

--
Martin

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/23/2010 09:55 PM, Martin Pool wrote:

> ... or, perhaps better, just use the abstraction across various
> methods provided by libsensors? People might also want to graph hdd
> temperatures?

How does that abstraction work? Can it tell what each "tempN" above is?
If yes, any particular reason why "sensors" doesn't use it?

>> One of the concerns I have is that the output of sensors is not always
>> accurate and can be confusing, with names we have no idea what they
>> represent, like temp1, temp2, etc.
>
> I agree, though this does seem to be a problem for acpi too?

Not in our experience, the thermal zones from acpi have been correct so
far both in values and in which component is being measured.

> Another problem, across all methods, is that some sensors seem stuck
> at unreasonable values like 0 or 127C.

Yes. Unfortunately that coincides with the maximum possible value for an
8 bit value, right?

> If I was going to programmatically reduce it to a single value, I
> would probably take the maximum plausible value at any moment across
> all sensors. Or do this per grouping, if we're getting any useful
> grouping metadata: the hottest probe in the drives is currently: 46C;
> the hottest probe in the cpu is 48C; etc.

Yeah, but sensors doesn't tell us which temp is cpu, which temp is hard
drive, etc. Unless the abstraction you mentioned above does.

> For things like drives or other swappable devices, users might care
> which particular drive is overheating; for cpu or motherboard
> measurement it seems to me not to be very meaningful.
>

- --
Andreas Hasenack
<email address hidden>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzs1KYACgkQeEJZs/PdwpAahACePM3xJk8WDs16pBlsyYCvPL3Z
JXwAoMilWFOrCkMjF6jxGfd+FJJS/Xnb
=86JN
-----END PGP SIGNATURE-----

On 24 November 2010 20:02, Andreas Hasenack <email address hidden> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 11/23/2010 09:55 PM, Martin Pool wrote:
>
>> ... or, perhaps better, just use the abstraction across various
>> methods provided by libsensors?  People might also want to graph hdd
>> temperatures?
>
> How does that abstraction work? Can it tell what each "tempN" above is?
> If yes, any particular reason why "sensors" doesn't use it?

But I think 'sensors' does use libsensors. At any rate its package
lm-sensors does depend on libsensors, and it can for example show hdd
temperatures. I haven't looked at the code so I would only be
guessing how it works.

At least on my machine it doesn't know where the tempN probes are.

>>> One of the concerns I have is that the output of sensors is not always
>>> accurate and can be confusing, with names we have no idea what they
>>> represent, like temp1, temp2, etc.
>>
>> I agree, though this does seem to be a problem for acpi too?
>
> Not in our experience, the thermal zones from acpi have been correct so
> far both in values and in which component is being measured.

I seem to recall just often seeing numbered zones in acpi, but you've
probably seen more different machines for this than I have.

>> Another problem, across all methods, is that some sensors seem stuck
>> at unreasonable values like 0 or 127C.
>
> Yes. Unfortunately that coincides with the maximum possible value for an
> 8 bit value, right?

In a way that's fortunate because you can easily conclude it's not a real value.

>> If I was going to programmatically reduce it to  a single value, I
>> would probably take the maximum plausible value at any moment across
>> all sensors.  Or do this per grouping, if we're getting any useful
>> grouping metadata: the hottest probe in the drives is currently: 46C;
>> the hottest probe in the cpu is 48C; etc.
>
> Yeah, but sensors doesn't tell us which temp is cpu, which temp is hard
> drive, etc. Unless the abstraction you mentioned above does.

When I run 'sensors' on my laptop, it does seem to include hdd
temperatures, labelled as such. (Or maybe it's the motherboard sensor
next to the hdd.)

I guess for drives what would be good is to run hddtemp; that could be
a separate bug:

mbp@grace% sudo hddtemp /dev/sd?
/dev/sda: ST31000528AS: 39°C
/dev/sdb: WDC WD10EACS-00ZJB0: 44°C
/dev/sdc: WDC WD10EACS-00D6B0: 47°C
/dev/sdd: WDC WD5000AAKS-22TMA0: 46°C
/dev/sde: WDC WD5000AAKS-22TMA0: 45°C
/dev/sdf: Generic Flash HS-CF: S.M.A.R.T. not available
/dev/sdg: Generic Flash HS-COMBO: S.M.A.R.T. not available

--
Martin

Status changed to 'Confirmed' because the bug affects multiple users.

This bug has not seen any activity in the last 6 months, so it is being automatically closed.

If you are still experiencing this issue, please feel free to re-open.

Landscape Team

So.. what is happening with this? It would be nice to be able to see my temperatures, which sensors is able to do.

We don't currently plan to fix this, the status of 'won't fix' is more appropriate.