Bug 6075

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.