Most recent kernel where this bug did not occur: Unknown Distribution: Fedora Core 4 Hardware Environment: Compaq Presario X1050 laptop Software Environment: n/a Problem Description: ACPI suspend and resume produces the following errors in dmesg. After resume, also the battery status is not displayed and the keyboard behaves erratically (missing and wrong characters). ACPI: read EC, IB not empty ACPI Exception (evregion-0409): AE_TIME, Returned by Handler for [EmbeddedControl] [20060127] ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.C046.C059.C0EA.C132] (Node dfea01e0), AE_TIME ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.C132] (Node c14dde20), AE_TIME ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.C11F._BST] (Node c14ddd60), AE_TIME ACPI: read EC, IB not empty ACPI Exception (evregion-0409): AE_TIME, Returned by Handler for [EmbeddedControl] [20060127] ACPI Exception (dswexec-0458): AE_TIME, While resolving operands for [AE_NOT_CONFIGURED] [20060127] ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.C046.C059.C0EA.C11D] (Node dfea0280), AE_TIME ACPI Error (psparse-0517): Method parse/execution failed [\_WAK] (Node c14dc500), AE_TIME ACPI Exception (hwsleep-0546): AE_TIME, During Method _WAK [20060127] ACPI: read EC, IB not empty ACPI Exception (evregion-0409): AE_TIME, Returned by Handler for [EmbeddedControl] [20060127] ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.C046.C059.C0EA.C132] (Node dfea01e0), AE_TIME ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.C132] (Node c14dde20), AE_TIME ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.C11F._BST] (Node c14ddd60), AE_TIME Steps to reproduce: Enter ACPI suspend and then resume on the above computer.
Created attachment 7324 [details] Full dmesg output from system bootup and suspend/resume The following were also tried to resolve this problem: -booting with "ec_intr=0" -Changing ACPI_EC_DELAY from 50 to 100 in drivers/acpi/ec.c -bootind with "lapic" Also, the contents of /proc/acpi/embedded_controller/C0EA/info both before and after suspend are: gpe bit: 0x1c ports: 0x66, 0x62 use global lock: no
Created attachment 7325 [details] Script used to perform suspend and resume
Still occurring on 2.6.16-rc6: ACPI: read EC, IB not empty ACPI Exception (evregion-0409): AE_TIME, Returned by Handler for [EmbeddedControl] [20060127] ACPI Exception (dswexec-0458): AE_TIME, While resolving operands for [AE_NOT_CONFIGURED] [20060127] ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.C046.C059.C0EA.C11D] (Node dfea0280), AE_TIME ACPI Error (psparse-0517): Method parse/execution failed [\_WAK] (Node c14dc500), AE_TIME ACPI Exception (hwsleep-0546): AE_TIME, During Method _WAK [20060127] ACPI: read EC, IB not empty ACPI Exception (evregion-0409): AE_TIME, Returned by Handler for [EmbeddedControl] [20060127] ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.C046.C059.C0EA.C132] (Node dfea01e0), AE_TIME ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.C132] (Node c14dde20), AE_TIME ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.C11F._BST] (Node c14ddd60), AE_TIME
>Back to C! Not sure the following error is related. But, it do make sense to solve it first. Could try comment out irqrouter_resume first? >Debug: sleeping function called from invalid context at mm/slab.c:2666 in_atomic():0, irqs_disabled():1 [<c015e094>] kmem_cache_alloc+0x54/0x70 [<c021039e>] acpi_os_acquire_object+0xb/0x36 [<c0224f5b>] acpi_ut_allocate_object_desc_dbg+0x10/0x3e [<c0224fce>] acpi_ut_create_internal_object_dbg+0xf/0x5e [<c022161f>] acpi_rs_set_srs_method_data+0x3d/0xba [<c010664c>] get_cmos_time+0x15c/0x170 [<c0228888>] acpi_pci_link_set+0xf4/0x168 [<c0228930>] irqrouter_resume+0x34/0x52 [<c025f781>] __sysdev_resume+0x11/0x80 [<c025f837>] sysdev_resume+0x47/0x70 [<c0264895>] device_power_up+0x5/0x10 [<c013cb55>] enter_state+0x175/0x1d0 [<c013cc45>] state_store+0x95/0xb0 [<c013cbb0>] state_store+0x0/0xb0 [<c01a18c9>] subsys_attr_store+0x29/0x40 [<c01a1e90>] sysfs_write_file+0xa0/0xf0 [<c01a1df0>] sysfs_write_file+0x0/0xf0 [<c01619ef>] vfs_write+0xbf/0x180 [<c01623f1>] sys_write+0x41/0x70 [<c0102e3d>] syscall_call+0x7/0xb PCI: Enabling device 0000:00:1d.0 (0000 -> 00
I don't think that problem is related, previous kernels didn't show the same error and had the same problem. Also filed a Fedora Core 5 bug entry on this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186346
Created attachment 7654 [details] Output from Fedora Core 5 kernel with ACPI debugging Attached is the dmesg output from boot, suspend and resume on the Fedora Core 5 kernel. I made a couple changes in drivers/acpi/ec.c: changed ACPI_EC_DELAY to 1000 (a full second) as well as changed the "read EC, IB not empty" output to be different in both places. You can see that it is the one before the read command has been issued, meaning the EC is showing the input-buffer is non-empty for a full second before anything was written to it. It seems the EC must be in some invalid or uninitialized state. I wonder if it doesn't like the order in which it is being initialized, i.e. the keyboard controller being initialized before the ACPI EC part or something? Could this be different on Windows?
Created attachment 8016 [details] Suspend output from 2.6.17-rc3 based Fedora kernel This is the output from Fedora kernel 2.6.16-1.2182_FC6 which is based on 2.6.17-rc3. There are actually 2 suspends in here. The problem is not as severe in this kernel, but definitely still present. The keyboard is not as badly hosed as previous kernels but the system still locks up when it tries to restart. The ACPI Embedded Controller/keyboard controller is clearly still NOT happy: i8042: failed to resume active multiplexor, mouse won't work. psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 Restarting tasks... done Thawing cpus ... ACPI: read EC, IB not empty ACPI Exception (evregion-0409): AE_TIME, Returned by Handler for [EmbeddedControl] [20060127] ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.C046.C059.C0EA.C132] (Node c1589c18), AE_TIME ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.C132] (Node c158587c), AE_TIME ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.C11F._BST] (Node c1585774), AE_TIME ACPI: read EC, IB not empty ACPI Exception (evregion-0409): AE_TIME, Returned by Handler for [EmbeddedControl] [20060127] ACPI Exception (dswexec-0458): AE_TIME, While resolving operands for [AE_NOT_CONFIGURED] [20060127] ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.C046.C059.C0EA.C11D] (Node c1589774), AE_TIME ACPI Error (psparse-0517): Method parse/execution failed [\_WAK] (Node c15844e0), AE_TIME ACPI Exception (hwsleep-0546): AE_TIME, During Method _WAK [20060127] ACPI Error (evevent-0312): No installed handler for fixed event [00000002] [20060127]
Updating version to 2.6.17-rc3 as still busted there.
Created attachment 8160 [details] script to suspend to ram (also removes usb and firewire modules) I had a similar issue with an HP Pavilion 3340EA. The modules that were causing the ACPI Exception were the ohci1394, ieee1394, uhci_hcd and ehci_hcd. A working suspend_to_ram script for this model is also attached. Note that: - in the original bug report, the used script doesn't remove these modules - I also use vbetool for the radeon - I also have a synaptics touchpad - The tests were made in FC4 2.6.16-1.2108_FC4 JPM
Hmm, it seems that unloading ohci1394, uhci_hcd and ehci_hcd prevents these errors from showing up. Question is, why.. I can see the USB modules potentially causing problems, if the BIOS is somehow reasserting control over the controller with USB legacy mode and fighting with the OS for the keyboard controller, but I'm not sure how the 1394 module could have this effect..
I thought this might be an ACPI DSDT problem, so I disassembled the DSDT and rebuilt it with IASL. The only error was on an embedded controller operation region field which was declared as AnyAcc instead of ByteAcc. I fixed this, rebuilt the DSDT and substituted it, but it made no difference with this problem.
Upon further investigation, this problem only shows up when ohci1394 is loaded. It appears that the lack of proper suspend/resume code has something to do with this problem, as the PCI configuration space for the 1394 controller is restored when the driver is not loaded, but is not when the driver is loaded. I created a patch which adds pci_save_state and pci_restore_state to the driver's suspend and resume functions, which appears to fix this problem. I've posted the patch to LKML for comment. Why this causes problems with ACPI and the keyboard controller, who knows..
fix-broken-suspend-resume-in-ohci1394-was-acpi-suspend.patch has now been added to the -mm tree. Think I will mark this resolved now..
According to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186346#c3 "This has been fixed in the latest 2.6.17 update kernels (fix was in upstream 2.6.17.2)." closed.