Bug 107151

Summary: Lenovo Ideapad S10-3t(Intel(R) Atom(TM) CPU N450 ) hangs coming out of S3 with intel_idle
Product: Power Management Reporter: Ville Syrjala (ville.syrjala)
Component: intel_idleAssignee: Chen Yu (yu.c.chen)
Status: CLOSED INSUFFICIENT_DATA    
Severity: normal CC: a.j.buxton, colin.king, feng.tang, jacob.jun.pan, lv.zheng, rui.zhang, szg00000
Priority: P1    
Hardware: Intel   
OS: Linux   
Kernel Version: 4.3.0 Subsystem:
Regression: No Bisected commit-id:
Attachments: [PATCH] intel_idle: Don't use on Lenovo Ideapad S10-3t

Description Ville Syrjala 2015-11-04 16:05:34 UTC 
Lenovo Ideapad S10-3t hangs coming out of S3 with intell_idle. The two workaround that seem to help are "intel_idle.max_cstate=0" or "nohz=off highres=off".

Other options tried:
 maxcpus=1
 nohpet
 hpet=disable
 intel_idle.max_cstate={1,2,3}
none of them help.

It seems intel_idle has always been flaky with this hardware. It used to work a little better in the past, but not perfectly.

I tried to bisect the total breakage starting from v3.11, and found the following commit to be at fault:
commit a8d46b9e4e487301affe84fa53de40b890898604
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Tue Sep 30 02:29:01 2014 +0200

    ACPI / sleep: Rework the handling of ACPI GPE wakeup from suspend-to-idle

Before that I observed three different behaviours for S3 resume:
a) sometimes it resumed OK
b) sometimes it resumed part way, but kbd/network etc. were still dead, but then pressing the power button made it finish the resume somehow
c) same as the previous, except the power button press also made it all the way to userspace and initiated a normal shutdown
The same kernel could exhibit both a) and b), or both a) and c).

After a8d46b9e4e48 it never resumes, no matter if I press the power button or not.
Comment 1 Ville Syrjala 2015-11-04 16:15:36 UTC 
Bunch of debug information with intel_idle:

# uname -a
Linux pnv-s10-3t 4.3.0-rc7-pnv+ #37 SMP PREEMPT Wed Nov 4 16:59:39 EET 2015 x86_64 x86_64 x86_64 GNU/Linux

# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.3.0-rc7-pnv+ root=/dev/sda1 ro drm.debug=0xe modprobe.blacklist=i915 text

# cat /proc/cpuinfo
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 28
model name	: Intel(R) Atom(TM) CPU N450   @ 1.66GHz
stepping	: 10
microcode	: 0x105
cpu MHz		: 1667.000
cache size	: 512 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 1
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm dtherm
bugs		:
bogomips	: 3324.86
clflush size	: 64
cache_alignment	: 64
address sizes	: 32 bits physical, 48 bits virtual
power management:

processor	: 1
vendor_id	: GenuineIntel
cpu family	: 6
model		: 28
model name	: Intel(R) Atom(TM) CPU N450   @ 1.66GHz
stepping	: 10
microcode	: 0x105
cpu MHz		: 1333.000
cache size	: 512 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 1
apicid		: 1
initial apicid	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm dtherm
bugs		:
bogomips	: 3324.86
clflush size	: 64
cache_alignment	: 64
address sizes	: 32 bits physical, 48 bits virtual
power management:

# grep . /sys/devices/system/cpu/cpuidle/*
/sys/devices/system/cpu/cpuidle/current_driver:intel_idle
/sys/devices/system/cpu/cpuidle/current_governor_ro:menu

# dmesg | grep idle
[    0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns
[    0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484882848 ns
[    0.052584] process: using mwait in idle threads
[    0.111214] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns
[    0.120133] cpuidle: using governor ladder
[    0.124038] cpuidle: using governor menu
[    0.641968] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
[    0.780495] intel_idle: MWAIT substates: 0x20220
[    0.780526] intel_idle: v0.4 model 0x1C
[    0.780536] intel_idle: lapic_timer_reliable_states 0x2
[    0.780562] tsc: Marking TSC unstable due to TSC halts in idle states deeper than C2
[    1.657475] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x17f68547f8a, max_idle_ns: 440795243686 ns
# grep . /sys/devices/system/cpu/cpu0/cpuidle/*/*
/sys/devices/system/cpu/cpu0/cpuidle/state0/desc:CPUIDLE CORE POLL IDLE
/sys/devices/system/cpu/cpu0/cpuidle/state0/disable:0
/sys/devices/system/cpu/cpu0/cpuidle/state0/latency:0
/sys/devices/system/cpu/cpu0/cpuidle/state0/name:POLL
/sys/devices/system/cpu/cpu0/cpuidle/state0/power:4294967295
/sys/devices/system/cpu/cpu0/cpuidle/state0/residency:0
/sys/devices/system/cpu/cpu0/cpuidle/state0/time:9079
/sys/devices/system/cpu/cpu0/cpuidle/state0/usage:9
/sys/devices/system/cpu/cpu0/cpuidle/state1/desc:MWAIT 0x00
/sys/devices/system/cpu/cpu0/cpuidle/state1/disable:0
/sys/devices/system/cpu/cpu0/cpuidle/state1/latency:10
/sys/devices/system/cpu/cpu0/cpuidle/state1/name:C1E-ATM
/sys/devices/system/cpu/cpu0/cpuidle/state1/power:0
/sys/devices/system/cpu/cpu0/cpuidle/state1/residency:20
/sys/devices/system/cpu/cpu0/cpuidle/state1/time:1107816
/sys/devices/system/cpu/cpu0/cpuidle/state1/usage:1462
/sys/devices/system/cpu/cpu0/cpuidle/state2/desc:MWAIT 0x10
/sys/devices/system/cpu/cpu0/cpuidle/state2/disable:0
/sys/devices/system/cpu/cpu0/cpuidle/state2/latency:20
/sys/devices/system/cpu/cpu0/cpuidle/state2/name:C2-ATM
/sys/devices/system/cpu/cpu0/cpuidle/state2/power:0
/sys/devices/system/cpu/cpu0/cpuidle/state2/residency:80
/sys/devices/system/cpu/cpu0/cpuidle/state2/time:3823349
/sys/devices/system/cpu/cpu0/cpuidle/state2/usage:3680
/sys/devices/system/cpu/cpu0/cpuidle/state3/desc:MWAIT 0x30
/sys/devices/system/cpu/cpu0/cpuidle/state3/disable:0
/sys/devices/system/cpu/cpu0/cpuidle/state3/latency:100
/sys/devices/system/cpu/cpu0/cpuidle/state3/name:C4-ATM
/sys/devices/system/cpu/cpu0/cpuidle/state3/power:0
/sys/devices/system/cpu/cpu0/cpuidle/state3/residency:400
/sys/devices/system/cpu/cpu0/cpuidle/state3/time:39588138
/sys/devices/system/cpu/cpu0/cpuidle/state3/usage:5546

# grep . /sys/devices/system/clocksource/clocksource0/{available,current}_clocksource
/sys/devices/system/clocksource/clocksource0/available_clocksource:hpet acpi_pm 
/sys/devices/system/clocksource/clocksource0/current_clocksource:hpet

# turbostat --debug sleep 10
turbostat version 4.8 26-Sep, 2015 - Len Brown <lenb@kernel.org>
CPUID(0): GenuineIntel 10 CPUID levels; family:model:stepping 0x6:1c:a (6:28:10)
CPUID(6): APERF, DTS, No PTM, No EPB
cpu0: Guessing tjMax 100 C, Please use -T to specify
cpu0: MSR_IA32_THERM_STATUS: 0x883b0000 (41 C +/- 1)
     CPU Avg_MHz   %Busy Bzy_MHz TSC_MHz CoreTmp
       -       9   11.64      79     109      45
       0      10   13.31      78     109      45
       1       8    9.98      81     109
10.011857 sec
Comment 2 Ville Syrjala 2015-11-04 16:16:28 UTC 
Bunch of debug information with acpi_idle:

# uname -a
Linux pnv-s10-3t 4.3.0-rc7-pnv+ #37 SMP PREEMPT Wed Nov 4 16:59:39 EET 2015 x86_64 x86_64 x86_64 GNU/Linux

# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.3.0-rc7-pnv+ root=/dev/sda1 ro drm.debug=0xe modprobe.blacklist=i915 text intel_idle.max_cstate=0

# cat /proc/cpuinfo
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 28
model name	: Intel(R) Atom(TM) CPU N450   @ 1.66GHz
stepping	: 10
microcode	: 0x105
cpu MHz		: 1667.000
cache size	: 512 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 1
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm dtherm
bugs		:
bogomips	: 3325.18
clflush size	: 64
cache_alignment	: 64
address sizes	: 32 bits physical, 48 bits virtual
power management:

processor	: 1
vendor_id	: GenuineIntel
cpu family	: 6
model		: 28
model name	: Intel(R) Atom(TM) CPU N450   @ 1.66GHz
stepping	: 10
microcode	: 0x105
cpu MHz		: 1333.000
cache size	: 512 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 1
apicid		: 1
initial apicid	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm dtherm
bugs		:
bogomips	: 3325.18
clflush size	: 64
cache_alignment	: 64
address sizes	: 32 bits physical, 48 bits virtual
power management:

# grep . /sys/devices/system/cpu/cpuidle/*
/sys/devices/system/cpu/cpuidle/current_driver:acpi_idle
/sys/devices/system/cpu/cpuidle/current_governor_ro:menu

# dmesg | grep idle
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.3.0-rc7-pnv+ root=/dev/sda1 ro drm.debug=0xe modprobe.blacklist=i915 text intel_idle.max_cstate=0
[    0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns
[    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.3.0-rc7-pnv+ root=/dev/sda1 ro drm.debug=0xe modprobe.blacklist=i915 text intel_idle.max_cstate=0
[    0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484882848 ns
[    0.051907] process: using mwait in idle threads
[    0.109223] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns
[    0.118134] cpuidle: using governor ladder
[    0.122037] cpuidle: using governor menu
[    0.643867] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
[    0.782385] intel_idle: disabled
[    0.836835] tsc: Marking TSC unstable due to TSC halts in idle
[    0.855059] ACPI: acpi_idle registered with cpuidle
[    1.652378] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x17f71e3eaef, max_idle_ns: 440795232193 ns

# grep . /sys/devices/system/cpu/cpu0/cpuidle/*/*
/sys/devices/system/cpu/cpu0/cpuidle/state0/desc:CPUIDLE CORE POLL IDLE
/sys/devices/system/cpu/cpu0/cpuidle/state0/disable:0
/sys/devices/system/cpu/cpu0/cpuidle/state0/latency:0
/sys/devices/system/cpu/cpu0/cpuidle/state0/name:POLL
/sys/devices/system/cpu/cpu0/cpuidle/state0/power:4294967295
/sys/devices/system/cpu/cpu0/cpuidle/state0/residency:0
/sys/devices/system/cpu/cpu0/cpuidle/state0/time:1286
/sys/devices/system/cpu/cpu0/cpuidle/state0/usage:3
/sys/devices/system/cpu/cpu0/cpuidle/state1/desc:ACPI FFH INTEL MWAIT 0x0
/sys/devices/system/cpu/cpu0/cpuidle/state1/disable:0
/sys/devices/system/cpu/cpu0/cpuidle/state1/latency:1
/sys/devices/system/cpu/cpu0/cpuidle/state1/name:C1
/sys/devices/system/cpu/cpu0/cpuidle/state1/power:0
/sys/devices/system/cpu/cpu0/cpuidle/state1/residency:2
/sys/devices/system/cpu/cpu0/cpuidle/state1/time:1152159
/sys/devices/system/cpu/cpu0/cpuidle/state1/usage:1580
/sys/devices/system/cpu/cpu0/cpuidle/state2/desc:ACPI FFH INTEL MWAIT 0x10
/sys/devices/system/cpu/cpu0/cpuidle/state2/disable:0
/sys/devices/system/cpu/cpu0/cpuidle/state2/latency:20
/sys/devices/system/cpu/cpu0/cpuidle/state2/name:C2
/sys/devices/system/cpu/cpu0/cpuidle/state2/power:0
/sys/devices/system/cpu/cpu0/cpuidle/state2/residency:40
/sys/devices/system/cpu/cpu0/cpuidle/state2/time:3798515
/sys/devices/system/cpu/cpu0/cpuidle/state2/usage:3442
/sys/devices/system/cpu/cpu0/cpuidle/state3/desc:ACPI FFH INTEL MWAIT 0x30
/sys/devices/system/cpu/cpu0/cpuidle/state3/disable:0
/sys/devices/system/cpu/cpu0/cpuidle/state3/latency:100
/sys/devices/system/cpu/cpu0/cpuidle/state3/name:C3
/sys/devices/system/cpu/cpu0/cpuidle/state3/power:0
/sys/devices/system/cpu/cpu0/cpuidle/state3/residency:200
/sys/devices/system/cpu/cpu0/cpuidle/state3/time:21250349
/sys/devices/system/cpu/cpu0/cpuidle/state3/usage:6632

# grep . /sys/devices/system/clocksource/clocksource0/{available,current}_clocksource
/sys/devices/system/clocksource/clocksource0/available_clocksource:hpet acpi_pm 
/sys/devices/system/clocksource/clocksource0/current_clocksource:hpet

# turbostat --debug sleep 10
turbostat version 4.8 26-Sep, 2015 - Len Brown <lenb@kernel.org>
CPUID(0): GenuineIntel 10 CPUID levels; family:model:stepping 0x6:1c:a (6:28:10)
CPUID(6): APERF, DTS, No PTM, No EPB
cpu0: Guessing tjMax 100 C, Please use -T to specify
cpu0: MSR_IA32_THERM_STATUS: 0x883a0000 (42 C +/- 1)
     CPU Avg_MHz   %Busy Bzy_MHz TSC_MHz CoreTmp
       -       7    9.74      72     113      46
       0       7   10.56      71     113      46
       1       7    8.92      74     113
10.005989 sec
Comment 3 Ville Syrjala 2015-11-04 16:22:10 UTC 
Created attachment 192081 [details]
[PATCH] intel_idle: Don't use on Lenovo Ideapad S10-3t

Patch to blacklist intel_idle on the machine using DMI, if no other solution is found.
Comment 4 Zhang Rui 2015-12-28 12:50:06 UTC 
(In reply to Ville Syrjala from comment #0)
> I tried to bisect the total breakage starting from v3.11, and found the
> following commit to be at fault:
> commit a8d46b9e4e487301affe84fa53de40b890898604
> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Date:   Tue Sep 30 02:29:01 2014 +0200
> 
>     ACPI / sleep: Rework the handling of ACPI GPE wakeup from suspend-to-idle
> 
so have you confirmed that this is the commit that introduces the problem?
Say, you can check out kernel source right before and after this commit and see if the problem exists or not.

BTW, to me, the only functional change made by this commit is that it enables the ACPI SCI during system suspend, which should take no effect for S3, IMO.
If you can confirm it is this commit that introduces the difference, I would be curious about if we should enable SCI for S3...
Comment 5 Ville Syrjala 2016-01-11 17:12:16 UTC 
(In reply to Zhang Rui from comment #4)
> (In reply to Ville Syrjala from comment #0)
> > I tried to bisect the total breakage starting from v3.11, and found the
> > following commit to be at fault:
> > commit a8d46b9e4e487301affe84fa53de40b890898604
> > Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > Date:   Tue Sep 30 02:29:01 2014 +0200
> > 
> >     ACPI / sleep: Rework the handling of ACPI GPE wakeup from
> suspend-to-idle
> > 
> so have you confirmed that this is the commit that introduces the problem?
> Say, you can check out kernel source right before and after this commit and
> see if the problem exists or not.

You didn't read what I wrote in the first comment?
Comment 6 Zhang Rui 2016-05-10 05:52:05 UTC 
(In reply to Ville Syrjala from comment #5)
> (In reply to Zhang Rui from comment #4)
> > (In reply to Ville Syrjala from comment #0)
> > > I tried to bisect the total breakage starting from v3.11, and found the
> > > following commit to be at fault:
> > > commit a8d46b9e4e487301affe84fa53de40b890898604
> > > Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > Date:   Tue Sep 30 02:29:01 2014 +0200
> > > 
> > >     ACPI / sleep: Rework the handling of ACPI GPE wakeup from
> suspend-to-idle
> > > 
> > so have you confirmed that this is the commit that introduces the problem?
> > Say, you can check out kernel source right before and after this commit and
> > see if the problem exists or not.
> 
> You didn't read what I wrote in the first comment?

Sorry, I missed your previous statement about this.
Comment 7 Zhang Rui 2016-05-10 05:59:11 UTC 
(In reply to Ville Syrjala from comment #0)
> Lenovo Ideapad S10-3t hangs coming out of S3 with intell_idle. The two
> workaround that seem to help are "intel_idle.max_cstate=0" or "nohz=off
> highres=off".
> 
> Other options tried:
>  maxcpus=1
>  nohpet
>  hpet=disable
>  intel_idle.max_cstate={1,2,3}
> none of them help.
> 
> It seems intel_idle has always been flaky with this hardware. It used to
> work a little better in the past, but not perfectly.
> 
> I tried to bisect the total breakage starting from v3.11, and found the
> following commit to be at fault:
> commit a8d46b9e4e487301affe84fa53de40b890898604
> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Date:   Tue Sep 30 02:29:01 2014 +0200
> 
>     ACPI / sleep: Rework the handling of ACPI GPE wakeup from suspend-to-idle
> 
> Before that I observed three different behaviours for S3 resume:
> a) sometimes it resumed OK
> b) sometimes it resumed part way, but kbd/network etc. were still dead, but
> then pressing the power button made it finish the resume somehow
> c) same as the previous, except the power button press also made it all the
> way to userspace and initiated a normal shutdown
> The same kernel could exhibit both a) and b), or both a) and c).
> 
> After a8d46b9e4e48 it never resumes, no matter if I press the power button
> or not.

so if you use intel_idle.max_cstate=0 before this commit, can you reproduce the problem as you described in b) and c)?
Comment 8 Ville Syrjala 2016-05-11 10:03:45 UTC 
(In reply to Zhang Rui from comment #7)
> (In reply to Ville Syrjala from comment #0)
> > Lenovo Ideapad S10-3t hangs coming out of S3 with intell_idle. The two
> > workaround that seem to help are "intel_idle.max_cstate=0" or "nohz=off
> > highres=off".
> > 
> > Other options tried:
> >  maxcpus=1
> >  nohpet
> >  hpet=disable
> >  intel_idle.max_cstate={1,2,3}
> > none of them help.
> > 
> > It seems intel_idle has always been flaky with this hardware. It used to
> > work a little better in the past, but not perfectly.
> > 
> > I tried to bisect the total breakage starting from v3.11, and found the
> > following commit to be at fault:
> > commit a8d46b9e4e487301affe84fa53de40b890898604
> > Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > Date:   Tue Sep 30 02:29:01 2014 +0200
> > 
> >     ACPI / sleep: Rework the handling of ACPI GPE wakeup from
> suspend-to-idle
> > 
> > Before that I observed three different behaviours for S3 resume:
> > a) sometimes it resumed OK
> > b) sometimes it resumed part way, but kbd/network etc. were still dead, but
> > then pressing the power button made it finish the resume somehow
> > c) same as the previous, except the power button press also made it all the
> > way to userspace and initiated a normal shutdown
> > The same kernel could exhibit both a) and b), or both a) and c).
> > 
> > After a8d46b9e4e48 it never resumes, no matter if I press the power button
> > or not.
> 
> so if you use intel_idle.max_cstate=0 before this commit, can you reproduce
> the problem as you described in b) and c)?

acpi_idle has always worked fine. Well, except with 4.6 it seems, which is a new regression :(
Comment 9 Alistair Buxton 2016-06-09 23:21:04 UTC 
I have the same hardware and the same problem. I also bisected the problem back to the same commit, a8d46b9e4e487301affe84fa53de40b890898604, and found this thread from googling the commit ID.

> After a8d46b9e4e48 it never resumes, no matter if I press the power button or
> not.

Actually it does. You have to wait for about 6-7 minutes after initiating resume. After resume, the system clock will be running exactly five minutes slow. It will always be exactly 300 seconds slow, which very strongly indicates something is hitting a timeout.

I bisected from 3.17 to 3.18-rc1 and also tested multiple newer kernels including 4.7-rc2, 4.4, 4.0, 3.19 and the 300 second lag was consistent across all of them.

Unfortunately due to the clock ending up wrong the logs do not indicate what is actually taking five minutes. This hardware does not have a serial port, so I am not sure what to do at this point to further debug.
Comment 10 Alistair Buxton 2016-06-09 23:28:19 UTC 
Also I should mention that I have the latest available BIOS release installed and I didn't notice any problems with suspend prior to a8d46b9e, but I didn't really look very hard. All tests were done using Ubuntu 16.04.
Comment 11 Colin Ian King 2016-06-09 23:50:46 UTC 
I vaguely recall seeing this issue on Atom based netbooks a long while back, I think the following commit had something to do with this issue:

6eb0a0fd059598ee0d49c6283ce25cccd743e9fc, ("i386: Handle missing local APIC timer interrupts on C3 state")

"Whenever we see that a CPU is capable of C3 (during ACPI cstate init),
 we disable local APIC timer and switch to using a broadcast from
 external timer interrupt (IRQ 0). This is needed because Intel CPUs
 stop the local APIC timer in C3.  This is currently only enabled for
 Intel CPUs."

I believe using nolapic_timer seemed to help on some classes of Atom netbooks that suffered from the 300 second delay in resume wakeup.
Comment 12 Alistair Buxton 2016-06-10 00:11:54 UTC 
Interesting that the commit is labeled i386. I'm running a 64 bit kernel. I think the N450 was the first Atom with 64 bit capability, so maybe this only got fixed on i386? This machine only supports 2GB memory so maybe few people use 64 bit on it.
Comment 13 Alistair Buxton 2016-06-10 00:18:21 UTC 
Okay, according to https://fedoraproject.org/wiki/Common_kernel_problems :

> nolapic_timer can be useful on i386; on x86_64 this option is called
> noapictimer 

So I booted with noapictimer and the system resumes instantly.
Comment 14 Alistair Buxton 2016-06-27 19:52:51 UTC 
I just tested a 32 bit kernel and it has the same problem.
Comment 15 Feng Tang 2016-06-30 06:34:02 UTC 
There was a very old similar bug for s10-3t, see https://bugzilla.kernel.org/show_bug.cgi?id=41932 

you may want to try its patch https://bugzilla.kernel.org/attachment.cgi?id=76071
Comment 16 Alistair Buxton 2016-07-09 14:06:13 UTC 
That patch fixes the problem on 3.18 at least.
Comment 17 Lv Zheng 2017-04-13 06:37:00 UTC 
Let me add a reference for this issue.
It's disscussed in LKML:
https://lkml.org/lkml/2016/5/11/238
And it might be better to read the thread from this point:
https://lkml.org/lkml/2016/5/16/439
Comment 18 Chen Yu 2017-08-14 07:38:50 UTC 
Hi @Ville Syrjala
According to your description in https://lkml.org/lkml/2016/5/16/439,
this issue was due to the system hang during invoking the _WAK, right? May I know
if you have further debugged on this issue and does it still exist in the kernel?
Thanks.
Comment 19 Zhang Rui 2017-10-10 06:12:36 UTC 
bug closed as there is no response from the bug reporter.
please feel free to reopen it if the problem can be reproduced in the latest upstream kernel.