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

Bug #680353 reported by Martin Pool on 2010-11-23
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Landscape Client
Wishlist
Unassigned
landscape-client (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: landscape-client

My machine 'grace' (GA-890GPA-UD3H motherboard) has thermal information available through libsensors and hddtemp, and this shows up in the Gnome sensors-applet. However, Landscape says just 'No temperature information is available.'

Running 'sensors' on the command line shows:

mbp@grace% sensors
it8720-isa-0228
Adapter: ISA adapter
in0: +1.20 V (min = +0.00 V, max = +4.08 V)
in1: +1.50 V (min = +0.00 V, max = +4.08 V)
in2: +3.25 V (min = +0.00 V, max = +4.08 V)
in3: +2.96 V (min = +0.00 V, max = +4.08 V)
in4: +3.09 V (min = +0.00 V, max = +4.08 V)
in5: +2.16 V (min = +0.00 V, max = +4.08 V)
in6: +4.08 V (min = +0.00 V, max = +4.08 V)
in7: +2.93 V (min = +0.00 V, max = +4.08 V)
Vbat: +3.23 V
fan1: 5578 RPM (min = 0 RPM)
fan2: 1240 RPM (min = 0 RPM)
fan3: 2500 RPM (min = 0 RPM)
fan5: 2343 RPM (min = 0 RPM)
temp1: +48.0°C (low = +127.0°C, high = +127.0°C) sensor = thermistor
temp2: +42.0°C (low = +127.0°C, high = +80.0°C) sensor = thermal diode
temp3: +45.0°C (low = +127.0°C, high = +127.0°C) sensor = thermistor
cpu0_vid: +0.513 V

k10temp-pci-00c3
Adapter: PCI adapter
temp1: +0.0°C (high = +70.0°C, crit = +67.0°C)

They do not come up as acpi sensors.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: landscape-client 1.5.5.1-0ubuntu0.10.10.0
ProcVersionSignature: Ubuntu 2.6.35-23.40-generic 2.6.35.7
Uname: Linux 2.6.35-23-generic x86_64
Architecture: amd64
Date: Tue Nov 23 13:59:41 2010
EcryptfsInUse: Yes
ProcEnviron:
 PATH=(custom, user)
 LANG=en_AU.utf8
 SHELL=/bin/zsh
SourcePackage: landscape-client

Martin Pool (mbp) wrote :
Andreas Hasenack (ahasenack) 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.

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.

Changed in landscape-client:
status: New → Confirmed
importance: Undecided → Wishlist
Andreas Hasenack (ahasenack) wrote :

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

Launchpad Janitor (janitor) wrote :

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

Changed in landscape-client (Ubuntu):
status: New → Confirmed

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

Changed in landscape-client:
status: Confirmed → Invalid
rebroad (rebroad) wrote :

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

David Britton (davidpbritton) wrote :

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

Changed in landscape-client:
status: Invalid → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers