Comment 31 for bug 100114

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