I'd agree with you on the CPU start order.
To pinpoint the offending code, I instrumented some resume code with printk's and an msleep(10) after them (HZ=1000), so the TCSEL timer can jump in and report (it reports only when it detects a difference with the previous value). Result from this kernel which has lots of debugging info too:
[ 1.240004] CPU1 is up
[ 1.240008] kernel/power/main.c#145: suspend_finish
[ 1.262189] ALSA sound/pci/hda/hda_intel.c:805: hda-intel: timer: TCSEL=7
[ 1.322099] usb 5-8: new high speed USB device using ehci_hcd and address 3
(...)
[ 1.759403] ACPI: EC: acpi_ec_wait timeout, status = 0, expect_event = 1
(...)
[ 1.761131] kernel/power/main.c#148: suspend_finish
[ 1.771415] kernel/power/main.c#150: suspend_finish
This tells us that suspend_finish() in kernel/power/main.c has the culprit:
pm_ops->finish(state); http://lxr.linux.no/source/kernel/power/main.c#L142 (my line numbers are slightly different)
Looking at the source, the only relevant call to pm_set_ops() is found in ACPI, so we need to look at acpi_pm_finish() http://lxr.linux.no/source/drivers/acpi/sleep/main.c#L138
I'd agree with you on the CPU start order. power/main. c#145: suspend_finish hda/hda_ intel.c: 805: hda-intel: timer: TCSEL=7 power/main. c#148: suspend_finish power/main. c#150: suspend_finish >finish( state); lxr.linux. no/source/ kernel/ power/main. c#L142 (my line numbers are slightly different) lxr.linux. no/source/ drivers/ acpi/sleep/ main.c# L138
To pinpoint the offending code, I instrumented some resume code with printk's and an msleep(10) after them (HZ=1000), so the TCSEL timer can jump in and report (it reports only when it detects a difference with the previous value). Result from this kernel which has lots of debugging info too:
[ 1.240004] CPU1 is up
[ 1.240008] kernel/
[ 1.262189] ALSA sound/pci/
[ 1.322099] usb 5-8: new high speed USB device using ehci_hcd and address 3
(...)
[ 1.759403] ACPI: EC: acpi_ec_wait timeout, status = 0, expect_event = 1
(...)
[ 1.761131] kernel/
[ 1.771415] kernel/
This tells us that suspend_finish() in kernel/power/main.c has the culprit:
pm_ops-
http://
Looking at the source, the only relevant call to pm_set_ops() is found in ACPI, so we need to look at acpi_pm_finish() http://