Latest working kernel version: never worked 100%, last best performance in 2.6.25 Earliest failing kernel version: Distribution: ArchLinux up-to-date Hardware Environment: MSI EX600 notebook Problem Description: I have MSI EX600 notebook. ACPI here was never working 100%, but since 2.6.22 it has really improved. 2.6.25.7 was the last version, where ACPI worked pretty good. Sometimes it has "crashed" (no battery, no AC, temperature at 146 C), but in less then minute it has restored to original values, and kept running for some time again. 2.6.25.8 came with Windows Vista ACPI tables. This notebook is recommended for Windows Vista, but paradoxly, this update broke the ACPI. Since this version, ACPI was running some time, than it crashed leaving nothing in dmesg or logs, but haven't restored till next reboot. I've updated to 2.6.26.2 few days ago and I decided to do something with it. Here (http://forums.gentoo.org/viewtopic.php?t=122145) I found, how to check, if my DSDT is buggy. When recompiling, I recieved following warning (seven times - just different lines): dsdt.buggy.dsl 5329: Acquire (MUTE, 0x03E8) Warning 1103 - Possible operator timeout is ignored ^ I fixed them (changing all the values in Acquire to 0xFFFF) and recompiled the DSDT. I also compiled kernel with ACPI debug option enabled. This option brought me following errors in dmesg: ACPI Error (evregion-0315): No handler for Region [EC__] (ffff88007f8145e8) [EmbeddedControl] [20080609] ACPI Error (exfldio-0291): Region EmbeddedControl(3) has no handler [20080609] ACPI Error (psparse-0530): Method parse/execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node ffff88007f815fc0), AE_NOT_EXIST ACPI Error (uteval-0232): Method execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node ffff88007f815fc0), AE_NOT_EXIST ACPI Error (evregion-0315): No handler for Region [EC__] (ffff88007f8145e8) [EmbeddedControl] [20080609] ACPI Error (exfldio-0291): Region EmbeddedControl(3) has no handler [20080609] ACPI Error (psparse-0530): Method parse/execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node ffff88007f815fc0), AE_NOT_EXIST ACPI Error (uteval-0232): Method execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node ffff88007f815fc0), AE_NOT_EXIST Full dmesg output (from 2.6.26.2) is here: http://pastebin.com/m1359a16 Bug itself: ACPI crashes without any trace in logs,dmesg or so. No way to find out why or when. Steps to reproduce: Buy MSI EX600 notebook, install kernel 2.6.25.8 or higher and wait.
Created attachment 17327 [details] Dmesg from 2.6.27-rc3
Created attachment 17328 [details] acpidump from 2.6.27-rc3
Created attachment 17379 [details] Debug init patch Please make a dmesg with this patch applied
Hi, Dan It seems that the warning message is related with the BIOS. > Name (MYEC, One) // the initial value should be zero. >Method (_REG, 2, NotSerialized) { If (LEqual (Arg0, 0x03)) { Store (Arg1, MYEC) } Before the _REG object for EC is evaluated, the flag of MYEC is already 1, which is used to determine whether EC space handler is installed. IMO this is not appropriate. In fact the initial value should be zero instead of one. After the following the commit is merged, maybe the _STA object will also be evaluated in order to check whether the MCFG area is reserved in ACPI motherboard resources when there exists the MCFG table (In the function of acpi_init). >commit 7752d5cfe3d11ca0bb9c673ec38bd78ba6578f8e > Author: Robert Hancock <hancockr@shaw.ca> > Date: Fri Feb 15 01:27:20 2008 -0800 >x86: validate against acpi motherboard resources In such case the _STA object of the battery(BAT1) will be evaluated as there exists the MCFG table on your laptop. Because the initial value of MYEC is one, it means that EC device is ready and the EC internal object will be accessed. But in fact the EC device isn't initialized correctly in the function of acpi_init. So it will print the following warning message. >ACPI Error (evregion-0315): No handler for Region [EC__] (ffff88007f8145e8) [EmbeddedControl] [20080609] Of course the above warning message is harmless. According to the above analysis the problem is related with the BIOS. IMO it is more appropriate to fix this by upgrading BIOS. Thanks.
Created attachment 17404 [details] Dmesg output Hi, here's the dmesg output with your patch applied. I'll be off for following 5 or 6 days, so I'll can't reply.
Created attachment 17429 [details] try the debug patch Will you please try the debug patch and see whether the problem still exists? In this debug patch the EC device is enabled immediately after ACPI full intialization. (The function of acpi_boot_ec_enable is moved from acpi_scan_init to acpi_init). Thanks.
Hi Yakui, The reason why acpi_boot_ec_enable exists is that ASUS does not allow for EC.REG method to be called too early. With your patch you are doing just that, thus breaking ASUS again. Regards, Alex. bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=11374 > > > > > > ------- Comment #6 from yakui.zhao@intel.com 2008-08-25 01:45 ------- > Created an attachment (id=17429) > --> (http://bugzilla.kernel.org/attachment.cgi?id=17429&action=view) > try the debug patch > > Will you please try the debug patch and see whether the problem still exists? > In this debug patch the EC device is enabled immediately after ACPI full > intialization. (The function of acpi_boot_ec_enable is moved from > acpi_scan_init to acpi_init). > > Thanks. > >
Hi, Alexey Understand what you said. From the kernel source code it seems that the function of acpi_scan_init follows the function of acpi_init in the boot phase. In my patch the function of acpi_boot_ec_enable is moved from acpi_scan_init to acpi_init, but it will be called after ACPI full initialization(acpi_initialize_objects). In fact the _INI/_REG object is already executed. I don't understand why some Asus laptops are broken by the patch in comment #6. Of course I will check it. thanks.
My distro kernel was upated to 2.6.26.3 an it all works now (no crashes). I decided to close the bug as it seems to be fixed. Thanks everyone for help.
Hi, Dan Do you mean that the system can work well now? Will you please double check whether the following message still exists? > ACPI Error (evregion-0315): No handler for Region [EC__] > (ffff88007f8145e8) [EmbeddedControl] [20080609] >ACPI Error (exfldio-0291): Region EmbeddedControl(3) has no handler [20080609] >ACPI Error (psparse-0530): Method parse/execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node ffff88007f815fc0), AE_NOT_EXIST In fact the above message won't break anything. Of course the system can work well. But it is confusing. Maybe we should also fix it.
Hi, the ACPI is now not crashing anymore. Dmesg still contains the EC error: ACPI: bus type pci registered PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255 PCI: Not using MMCONFIG. PCI: Using configuration type 1 for base access ACPI: EC: Look up EC in DSDT ACPI: Interpreter enabled ACPI: (supports S0 S1 S3 S4 S5) ACPI: Using IOAPIC for interrupt routing PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255 ACPI Error (evregion-0316): No handler for Region [EC__] (ffff81007f8175e8) [EmbeddedControl] [20080321] ACPI Error (exfldio-0290): Region EmbeddedControl(3) has no handler [20080321] ACPI Error (psparse-0530): Method parse/execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node ffff81007f81a000), AE_NOT_EXIST ACPI Error (uteval-0233): Method execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node ffff81007f81a000), AE_NOT_EXIST ACPI Error (evregion-0316): No handler for Region [EC__] (ffff81007f8175e8) [EmbeddedControl] [20080321] ACPI Error (exfldio-0290): Region EmbeddedControl(3) has no handler [20080321] ACPI Error (psparse-0530): Method parse/execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node ffff81007f81a000), AE_NOT_EXIST ACPI Error (uteval-0233): Method execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node ffff81007f81a000), AE_NOT_EXIST PCI: MCFG area at e0000000 reserved in ACPI motherboard resources PCI: Using MMCONFIG at e0000000 - efffffff ACPI: EC: non-query interrupt received, switching to interrupt mode ACPI: EC: GPE storm detected, disabling EC GPE ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62 ACPI: EC: driver started in poll mode ACPI: PCI Root Bridge [PCI0] (0000:00) There are some minor changes from last check on 2.6.26.2 and I dunno if it is important or not, so I posted whole part around the EC error.
shipped in linux-2.6.28-rc1 closed commit 455c8793d2c49eaecad038c8de83dade9fc3759f Author: Zhao Yakui <yakui.zhao@intel.com> Date: Mon Oct 6 10:31:36 2008 +0800 ACPI: Enable EC device immediately after ACPI full initialization