On Mon, 2007-06-11 at 21:58 +0200, Maciej Rutecki wrote:
> Mircea Bardac pisze:
> > Hi all,
> >
> > I'm currently running kernel 2.6.21.3 on a HP nx6325.
> >
> > I like having in the taskbar information about cpu/mem/temperature/etc. I
> > found a strange behaviour monitoring the ACPI provided temperature. It
> > currently shows for example 48C constantly, for lots of minutes.
> >
> > Doing a: dd if=/dev/urandom of=/dev/null increases the CPU usage and
> > temperature should increase too. The ACPI temperature stays the same though.
> >
> > I have also loaded the lm_sensors modules which, after some monitoring,
> > appear
> > to be working right, meaning "it shows an increasing temperature if the CPU
> > usage increases".
> >
> > # cat /proc/acpi/thermal_zone/TZ1/temperature && sensors
> > temperature: 48 C
> > k8temp-pci-00c3
> > Adapter: PCI adapter
> > Core0 Temp:
> > +54°C
> > Core1 Temp:
> > +53°C
> >
> >
> > The ACPI temperature increases only when the trip-point is reached. I hear
> > the
> > fans starting. When the fans stop, the temperature drops "hard" to the
> > previous value.
> >
> > I've changed the polling frequency to 1:
> > # cat /proc/acpi/thermal_zone/TZ1/polling_frequency
> > polling frequency: 1 seconds
A value of 1 sec is a bad idea, I remember a report were things got
stuck because of too high polling freq.
The HPs normally throw thermal events correctly, better disable it and
set it to 0.
> >
> > I got the same effect: I can't see the temperature change dynamically,
> > degree
> > by degree. Also, in a test, the sensor went up to 60-65C and the trip-point
> > did't activate. This was with polling set to 1.
> >
>
> Similar on nx6310. Sometimes when I turn on laptop when CPU temperature
> (first thermal zone - TZ0) is above 1st trip point the fan doesn't turn
> on now, but only when second trip point was reached.
I've sent a little How-To some days ago:
Documentation - How to debug ACPI Problems
Len, what is your opinion about the HowTo?
Will you add it as it is?
I'd start to disassemble the DSDT.
Have a look at the _TMP code. There often are hard coded temperature
values. I expect they come from some BIOS setting or could be triggered
through applications that access the fan/temp directly. It could also be
that your EC is confused or something else.
You could (see the HowTo):
- 3.2.3 Using ACPI_DEBUG ASL debug object
-> Go to the _TMP func and cluster everything with
store (MONITOR_VAR, debug)
- 3.2.4 Using ACPI_DEBUG acpi_dbg_layer and acpi_dbg_level kernel
variables
-> Go to drivers/acpi/thermal.c when the temperature is invoked,
increase acpi_debug_level before evaluate_...("_TMP",..) is invoked
and decrease it afterwards. Only set flags you think are useful, I'd
start with exec, value, IIRC there also is some I/O or hardware
access flag. Always let the last 5 bit set 0x1F
(err,warn,deb,info,..)
BTW: Temperature passed through _TMP is:
1/10 Kelvin
Means 40C is a value of:
(273 + 40 ) * 10 = 3130 (0xC3A)
You might search for a hard coded value like that which matches yours.
Which kernel are you using?
Best you try the latest...
Is psmouse compiled as module?
Psmouse is known that it could interfere with ACPI on HP laptops and
lm_sensor modules also. Is it better without?
If latest kernel is affected, you best open a bug bugzilla.kernel.org,
attach dmesg, acpidump and everything else you find out. Pls CC me then.
Thomas
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
