Kernel Bug Tracker – Bug 8110
insanely high temperature on bootup (e.g. 3517 C) - HP/Compaq nx8220, nc6000, nc8000 - 2.6.19 regression
Last modified: 2008-10-17 21:40:57 UTC
Most recent kernel where this bug did *NOT* occur: 22.214.171.124
Hardware Environment: HP/Compaq nx8220 (and nc6000, nc8000)
Since I'm using kernel 2.6.20, on some fresh start-ups ACPI reports insanely
high temperatures of some thousand degrees C for thermal zone TZ3. I don't
exactly know what this sensor does - TZ1 is CPU temperature, TZ2 graphics chip,
TZ4 shows speed of CPU fan in % - I guess TZ3 shows some kind of case
temperature. Normal values for TZ3 are about 32C.
Another user on some forum has the same problem using a nc6000, yet another one
uses a nc8000 and kernel 2.6.19 (which I personally never installed/used). So I
guess the problem began with 2.6.19.
As I'm using powersaved, the system immediately shuts down on boot time, when
powersaved starts. Messages in syslog are sth. like:
ACPI: Critical trip point
Critical temperature reached (3264 C), shutting down.
The temperature shown is always different, mostly around 3000C. A new startup
after this shutdown (booting the same kernel) leads to the same situation, until I:
- boot with acpi=off - only resolves the issue for that boot up
- OR boot older kernel 126.96.36.199 - after that you can reboot into 2.6.20 w/o the
- OR remove AC and battery and plug it in again
Steps to reproduce:
issue happens sporadically on "fresh" power-on - no way to reproduce it, yet...
Created attachment 10642 [details]
don't read status until it's updated
Please try if this patch helps.
patch is against 2.6.21-rc3.
Hi Alexey, thanks for your reply! I'll try it ASAP... But I guess it'll take a
while to test whether the bug is gone. As I said: It only occurs from time to time.
I was able to make Acer Ferrari 3200 to fall into such "broken EC" mode every time,
and this patch helps to recover from such state.
Will wait for your tests...
patch in comment #1 applied to acpi-test
I get this error compiling 2.6.21-rc3 with your patch:
drivers/acpi/ec.c: In function 'acpi_fake_ecdt_callback':
drivers/acpi/ec.c:815: error: 'ec' undeclared (first use in this function)
drivers/acpi/ec.c:815: error: (Each undeclared identifier is reported only once
drivers/acpi/ec.c:815: error: for each function it appears in.)
What to do?
change "ec" to "ec_ecdt" on this line.
shipped in 2.6.21-rc3-git6
I wonder why the bug got closed although I haven't reported any success yet...
Anyway. I finally encountered the thousand-degrees-bug with 2.6.20 again. So my
strategy was to test, whether the patched 2.6.21-rc3 boots right after 2.6.20
auto-shutdowns. And it did just like 2.6.18 does! So I guess the problem is
really fixed and the bug can really be closed ;-)
The only thing I did not, was to use 2.6.21-rc3 for a longer period of time as
there are missing some other kernel patches I cannot do without. Another thing:
While booting 2.6.18 always "cures" the problem for the following bootups of
2.6.20 (just like removing the battery does), booting 2.6.21-rc3 only fixes the
issue for one next bootup of 2.6.20.
Thanks for the patch & your help! Now let's wait for the kernel to be released!
Thanks for the confirmation, Martin.
Re: bug states
RESOLVED means there is a patch available to test.
CLOSED means that the patch that is thought to address
the symptom has shipped upstream.
In this case there was another machine with a similar
problem that suggested that this fix would work,
and we reviewed and discussed the patch in detail,
so I closed it when the fix shipped upstream.
If it turns out that I was premature in closing the report,
and that sometimes happen, anybody can simply re-open it
when it is confirmed the issue is still present.
Can you attach the output of acpidump?
Will you please confirm whether the system can work well on the latest kernel 2.6.27-rc5?
From the patch in comment #1 it seems that the EC status register can't reflect the correct status of EC controller before the EC GPE interrupt is triggered. It seems weird according to the ACPI spec.
Will you please confirm whether the windows can work on this system? If windows can work, please attach the output of acpidump.