Most recent kernel where this bug did *NOT* occur: 2.6.18.2 Distribution: Debian/SID Hardware Environment: HP/Compaq nx8220 (and nc6000, nc8000) Software Environment: Problem Description: 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 2.6.18.2 - after that you can reboot into 2.6.20 w/o the problem - 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: CC drivers/acpi/ec.o 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 closed
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! Martin
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.
Hi, Martin Can you attach the output of acpidump? thanks.
Hi, Martin 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. Thanks.