Bug#487287: acpi: Negative value is show for temperature, fan constantly on
Am Dienstag, 24. Juni 2008 13:35 schrieb Michael Meskes:
> On Tue, Jun 24, 2008 at 07:42:28AM +0200, Adolf Winterer wrote:
> > > One more test please. Could you install and boot into the current
> > > 2.6.25 kernel in sid?
> >
> > I'd like to skip that, if possible, because as far as I know the NVidia
> > driver will not work with 2.6.25, which would leave me with nv, the 2D
> > only driver. Is there another way of testing this?
>
> I don't really see the problem. You can have both kernels installed at
> the same time. Just install the 2.6.25 package, boot into this kernel
> once, test acpi, boot back into 2.6.24 and remove the 2.6.25 package
> again.
Hello Michael,
I have a second system available now which shows the same behaviour, it is
also a Shuttle barebone, but it is brand new and still available for tests. I
installed the OS which installed kernel 2.6.22 (lenny). The temperature is
always reported to be 40 degrees C, absolutely independent from the
circumstances (yesterday and today). I updated to kernel 2.6.24 (lenny).
Nothing changed. Fan is on, temperature is 40 C. Then I updated to 2.6.25
(sid). And again: no change in temperature or fan state.
After that I did some more research and found that value stored in the file
/proc/acpi/thermal_zone/THRM/polling_frequency
is always "<polling disabled>". I guess this indicates that the values never
gets updated. Neither the temperature nor the state of the fan.
Asking Google I found some reports in blogs and fora (Debian forum and Ubuntu
forum) reporting the same problem: Absolutely NO update of the temperature
and wildly absurd values (everything from -270 C to over 80 C).
Some reporters could fix the problem by manually changing the dsdt (reading
the table into a file, disassembling it, changing the code, recompiling it
and then copying it back into the original place). The temperature is
reported correctly the and gets updated. And the fan is controlled
accordingly.
There should be a repository of dsdt files on
<http://www.lesswatts.org/projects/acpi/>, but I could not access the site as
the connection always times out.
Here are the first bytes of my dsdt of the older system:
00000000 44 53 44 54 85 42 00 00 01 0b 58 50 43 20 20 20 |DSDT.B....XPC |
00000010 53 44 33 32 56 31 30 00 00 10 00 00 4d 53 46 54 |SD32V10.....MSFT|
The systems that have been reported to be affected have been from many major
brands, so this seems to be more or less widespread.
Regards,
Adolf
> Michael
Reply to: