Latest working kernel version: None Earliest failing kernel version: 2.6.26.5 Distribution: Gentoo Hardware Environment: LG R500 Laptop, T7300, 2GB Memory, 160GB SATA 3Gb/s, Robson 1GB, NVIDIA 8600M GS 250MB, Authentec Fingerprint Reader, Infineon TPM Software Environment: Tested with a mainline Kernel, acpid, cpufreqd, syslog-ng, vixie-cron, and whitout NVIDIA module :P Problem Description: When the system is booting the Kernel reports an error on the DSDT table. The problem is that the table seems to be compiled with the Intel compiler. I don't know if this is a issue with the Kernel ACPI or with the table itselt, since both, Kernel and compiler, follow the ACPI standart (Microsoft counterparts are way more forgiving). Other problem is that the FAN0 is allways reported to be off, even though it is working (maybe it is related to the DSDT error?). Power button, lid, hibernate, suspend work great (even though, I only tested with the TuxOnIce patch set). Steps to reproduce: Boot the system. Notes: This happens with both the mainline Kernel, as well with the TuxOnIce Gentoo patched kernel sources. Using or not the NVIDIA module, doesnt change the outcome.
Created attachment 17910 [details] Full dmesg log
Created attachment 17911 [details] Dumped and decompiled DSDT table
A correction. Replace the following sentence: "The problem is that the table seems to be compiled with the Intel compiler." With: "The table seems to be compiled with the Intel compiler." (In reply to comment #0) > Latest working kernel version: None > Earliest failing kernel version: 2.6.26.5 > Distribution: Gentoo > Hardware Environment: LG R500 Laptop, T7300, 2GB Memory, 160GB SATA 3Gb/s, > Robson 1GB, NVIDIA 8600M GS 250MB, Authentec Fingerprint Reader, Infineon TPM > > Software Environment: Tested with a mainline Kernel, acpid, cpufreqd, > syslog-ng, vixie-cron, and whitout NVIDIA module :P > > Problem Description: When the system is booting the Kernel reports an error > on > the DSDT table. The problem is that the table seems to be compiled with the > Intel compiler. I don't know if this is a issue with the Kernel ACPI or with > the table itselt, since both, Kernel and compiler, follow the ACPI standart > (Microsoft counterparts are way more forgiving). Other problem is that the > FAN0 > is allways reported to be off, even though it is working (maybe it is related > to the DSDT error?). Power button, lid, hibernate, suspend work great (even > though, I only tested with the TuxOnIce patch set). > > Steps to reproduce: Boot the system. > > Notes: This happens with both the mainline Kernel, as well with the TuxOnIce > Gentoo patched kernel sources. Using or not the NVIDIA module, doesnt change > the outcome. >
Please attach the output of lspci -vxxx, acpidump. Thanks.
Created attachment 17947 [details] lspci -vxxx log
Created attachment 17948 [details] acpidump log
Hi, Saphex Thanks for the info. From the description it seems that there exist the following issues on your laptop. a. the warning message > No handler for Region [ECF2] (ffff81007f859f18) [EmbeddedControl] [20080321] > ACPI Error (exfldio-0290): Region EmbeddedControl(3) has no handler [20080321] > ACPI Error (psparse-0530): Method parse/execution failed [\_GPE._L02] (Node ffff81007f861490), AE_NOT_EXIST This is related with BIOS. Before the EC is not initialized correctly, the L02 GPE is fired, in which the EC internal register will be accessed(In the P8XH object). >Store (P80D, \_SB.PCI0.LPCB.EC.DBGC) In fact it should be : If (ECON) { Store (P80D, \_SB.PCI0.LPCB.EC.DBGC) } Of course the above message is harmless. After the EC is initialized correctly, there is no such warning message. b. the FAN0 reports to be off although the FAN device is working From the acpidump we can know that the ACPI FAN0 device is turned on/off by controlling the CTHT power resource. And it is ridiculous that the CTHT power resource is controlled by read/writing the CPU throttling register. >Method (STHT, 0, Serialized) > { > Store (0x06, TDTY) //TDTY, THTL is the CPU throttling controll register > Store (One, THTL) It seems that the FAN device is not controlled by ACPI. Maybe it is up to BIOS. And this is not the fault of Linux ACPI. c. EC GPE storm (ACPI: EC: GPE storm detected, disabling EC GPE) It seems that the EC GPE storm also happens on your laptop. This issue is related with the hardware. But how to workaround this is in discussion. Please see this issue on bug 9998/10724/11549/11309. thanks.
Yes, FAN controlling must be done at BIOS level (there are some BIOS options related to the FAN). As for the EC GPE storm, it doesn't seem to create the kind of problems reported on those bug reports. Will try with the latest Kernel to see if the storm still happens. Best regards.
Tried the latest Kernel 2.6.27-rc7 and the storm still occured. But I dont think it represents a problem since everything is working as it should with the EC driver in poll mode. A workaround shouldnt be needed.
Thanks for the confirmation. And it seems that your laptop still can work well although the EC GPE storm happens. Do you have opportunity to try the patches of 664d080c41463570b95717b5ad86e79dc1be0877#C9,10,11,12 and see whether the GPE storm message still exists? Thanks.
Sorry I paste the incorrect link. Do you have opportunity to try the patches of http://bugzilla.kernel.org/show_bug.cgi?id=11309#C9,10,11,12 and see whether the GPE storm message still exists? Thanks.
Hi, I tryed the patchs that you indicated above. I wanted to know wich patch solved the problem, so I decided to patch one by one, removing the last one before I applied the next (this way I could verify if it was a combination of patches or only one patch that solved the problem). The last patch add to be done manually, because the patch would only be completly successfull if there was other patches applyed. After four Kernell rebuilds and four reboots, the patch that solved the issue was the last one. I was never fan of delays to fix problems (even though this is a hardware problem, as you say). When I was manually patching I notice that the code wouldn't activate the poll mode anymore, so I wanted to ask if instead of adding more delay when a storm occurs, if we could enable the poll mode. For example, when the first storm occurs add the delay to prevent the next, when the second one occurs put it to poll mode. Is it a good idea? I guess it wont make much difference but isnt it saffer to be in poll mode than in interrupt mode when we have a faulty hardware that causes "thunders"? (I don't quite understand the difference between the two, only that one is activated by hardware interrupts??).
Created attachment 18010 [details] Delay patch for unpatched ec.c
I forgot to mention, in the BIOS is posible to control the fan, theres a option called "Automatic", it means the fan will work depending on thermal profiles. It is even possible to conrtol the fan behavior depending on the power supply (AC, DC). I still can control my fan with the appropriate Fn combination, supporting the theory that the ACPI doesn't have a thing to do with the fan, otherwize it wouldn't work would it?
Hi, Saphex Thanks for your problem. Only the last patch is useful for your laptop. In this patch if too many EC GPE interrupts happens in the same jiffies, it will add some delay to reduce the number of EC GPE interrupts. In such case it won't be switched to polling mode. In fact when the EC GPE storm is detected on the current upstream kernel, it will be switched to polling mode and EC GPE will also be disabled. It means that EC driver will work in polling mode while doing EC transaction. But unfortunately the EC notification event will be lost on some broken laptops. If the EC GPE is still enabled, there still exists a lot of EC GPE interrupts while doing EC transaction. Maybe it will break other laptops(For example: bug 9998). So it is difficult to decide what to do. In my patch when the EC GPE storms happens, the delay is added to reduce the number of EC GPE interrupts. But EC will continue its working flowchart.(For example: it will work in interrupt-driven mode and EC GPE is still enabled).(In fact my patch is useful for the broken BIOS and it won't affect the normal laptops). Of course it is ugly to add some delay in EC GPE handler. And someone disagree with it.
Hi, Saphex What you said in comment #14 is right. It seems that the FAN is controlled by the BIOS. The ACPI FAN device is bogus and it can't control the true FAN device. It seems that the EC notification event is triggered while using Fn combination, which will trigger SMI interrupt in the correspond _Qxx object. In such case BIOS can control the FAN speed according to the user requirment. So on your laptop ACPI has nothing to do with the FAN. thanks.
Well I might just disable the Fan support in Kernel, since it aint doing nothing. My laptop comes with a application called "LG On Screen Display" that allows the user, under Windows, to control the wireless, bluetooth, fan, audio volume and surrond system. For what I could get out of it (trough debugging since LG support suck in this kind of matters), is that it's using WMI for some stuff the application does. After checking in the Kernel the WMI experimental support I started looking at the driver code and found out that WMI is related to EC and a device called AWM0 (PNP0C14 is the important string here, 'cause it also can be found in the LG application). After that I started checking the acer-wmi code and I will try to port the Windows application functionality to Linux, and maybe I will come up in the future with something like a lge-wmi :P I just need to get the GUID for my laptop, what values are needed to write/read, ect... figure out how it works. More debugging on the way :) as well as some documentation reading :(
Hi, Saphex Now the wmi driver (drivers/acpi/wmi.c) is already shipped from the kernel of 2.6.25-rc1. Please try to use the latest kernel linux kernel and see whether the FAN device can be controlled through WMI driver. At the same time the following warning is related with the BIOS and we can't workaround it in kernel. In fact it is confusing but harmless. After the EC device is initialized, it can work normally. > ACPI Error (evregion-0316): No handler for Region [ECF2] (ffff81007f859f18) [EmbeddedControl] [20080321] > ACPI Error (exfldio-0290): Region EmbeddedControl(3) has no handler [20080321] > ACPI Error (psparse-0530): Method parse/execution failed [\P8XH] (Node ffff81007f846c70), AE_NOT_EXIST > ACPI Error (psparse-0530): Method parse/execution failed [\_GPE._L02] (Node ffff81007f861490), AE_NOT_EXIST From the acpidump we can know that the FAN device can't be controlled by ACPI. It is not ACPI fault. Your system can work well although EC GPE storm happens. At the same time the corresponding patch already exists. http://bugzilla.kernel.org/show_bug.cgi?id=11549#C11. So the bug will be rejected as it is related with BIOS.
Ok thanks for all the help. Learned alot :)