FS#42820 - [linux] 3.17.3 not waking up after suspend-to-RAM

Attached to Project: Arch Linux
Opened by Natrio (natrio) - Monday, 17 November 2014, 17:39 GMT
Last edited by Evangelos Foutras (foutrelis) - Sunday, 07 December 2014, 08:16 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture i686
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 23
Private No

Details

The kernel normally going to suspend, but after power resuming seems to be dead – no video, no ping, no sounds and no keyboard lights.

On linux-3.17.2 all works Ok.
On x86_64 all works Ok.

CPU: Intel Celeron G530
M.B: Gigabyte H61M-S2PV
Chipset: Intel H61 Express
This task depends upon

Closed by  Evangelos Foutras (foutrelis)
Sunday, 07 December 2014, 08:16 GMT
Reason for closing:  Fixed
Additional comments about closing:  linux 3.17.5-1
Comment by Ruben Herrero (herrecito) - Monday, 17 November 2014, 21:34 GMT
I'm having the same issue in my MSI Wind U100 which has an Intel Atom N270.

It worked fine with 3.17.2-1 also.
Comment by Natrio (natrio) - Tuesday, 18 November 2014, 07:43 GMT
It seems to be i686 build of linux-3.17.3 can't wake after suspend on any tested machines.
Comment by Gianpiero (4javier) - Tuesday, 18 November 2014, 17:23 GMT
Same problem. x86 32 bit here. Forced to hard reset, no entries after suspend into journal.
VGA x300 (rv370) with radeon driver.
Motherboard Asus P5P43TD PRO
Comment by karamba (vic3apex) - Tuesday, 18 November 2014, 20:13 GMT
Same issue
Intel Core i3-3110M
Intel Corporation 3rd Gen Core processor Graphics Controller
Comment by Yaroslav Zenin (kiotoze) - Thursday, 20 November 2014, 07:32 GMT
Also have this issue on hp6820s 32bit. Switch back to 3.17.2-1
Comment by Yannick Lange (FoolEcho) - Friday, 21 November 2014, 12:00 GMT
Same issue with an eeepc 1005HA (32 bits).
Kernel 3.17.2 works fine.
Comment by Nesser (Decepteiskon) - Friday, 21 November 2014, 13:44 GMT
Samsung N150 here (Atom N450 Intel Gma3150) using 3.17.3-3 kernel from linux-ck repo. Not same kernel, but same behavior. Probably mainline 3.17.3 related.
Comment by Tom Wong-Cornall (xwhatsit) - Saturday, 22 November 2014, 23:34 GMT
Same issue, using i686 (not x86_64) on a Thinkpad X220 with a Core i5-2410M. Downgrading to 3.17.2 seems to fix it. Is everybody so far running 32-bit? Haven't managed to spot a mailing list thread re. upstream yet.
Comment by Glenn (grepfor) - Sunday, 23 November 2014, 01:41 GMT
Same issue, i686 on Thinkpad T43, Pentium M.

For me, reverting to 3.17.2 or 3.17.1 does NOT solve the problem, it changes
the symptoms: With either of those kernels, the machine will not remain in suspend;
it resumes autonomously a few seconds after suspending.

Reverting to 3.16.4 restores fully working suspend/resume operation.
Comment by SATO Tatsuya (tattsan) - Sunday, 23 November 2014, 03:52 GMT
Same issue, i686 on Thinkpad X40, Pentium M.

I tested linux 3.17.4-1 (testing repository), but the problem was not solved.
Comment by Natrio (natrio) - Monday, 24 November 2014, 07:58 GMT
Can anyone to do git bisect for this bug?
https://bugzilla.kernel.org/show_bug.cgi?id=88391
Comment by Daniel Lublin (quite) - Monday, 24 November 2014, 08:23 GMT
Same here, i686 on Thinkpad X60
Comment by Amanda Furrow (afurrow) - Monday, 24 November 2014, 16:28 GMT
eeePC 901, same issue, 3.17.2-1-ARCH resumes from suspend but 3.17.3-1-ARCH does not.
Comment by Tom Wong-Cornall (xwhatsit) - Monday, 24 November 2014, 20:32 GMT
It probably doesn't need to be said, but switching to x86_64 makes this go away (this issue was the final push I needed to switch to 64 bit on my laptop).

I cannot help with a bisect after reinstalling as 64 bit, and I don't have another hard-drive lying around unfortunately.
Comment by Dani Ramirez (avenita) - Tuesday, 25 November 2014, 15:02 GMT
Same issue on Thinkpad X60 Tablet. CoreDuo L2500
doesnt resume atfer suspend to ram on 3.17.3-1 i686
journalctl doesnt contain any message atfer suspend
resume works fine on 3.17.2-1 i686 after downgrade
cant test x86-64 as this CPU is 32bit only
Comment by Natrio (natrio) - Wednesday, 26 November 2014, 06:05 GMT
https://bugzilla.kernel.org/show_bug.cgi?id=88391#c4

Finally, it was bisected to "fix" of this bug:
https://bugs.archlinux.org/task/42689
https://bugzilla.kernel.org/show_bug.cgi?id=88001
whith reloading of CPU microcode after suspend>resume.
Comment by Natrio (natrio) - Wednesday, 26 November 2014, 13:07 GMT
>> Borislav Petkov 2014-11-26 12:18:38 UTC
> temporary workaround is to disable the microcode loader, just add "dis_ucode_ldr" to your kernel command line.

And it seems to be this patch
https://projects.archlinux.org/svntogit/packages.git/tree/trunk/fix_CPU0_microcode_on_resume.patch?h=packages/linux
is not in mainline kernel 3.17.3, but was manually added in Arch Linux PKGBUILD since 3.17.3
Comment by SATO Tatsuya (tattsan) - Wednesday, 26 November 2014, 15:20 GMT
The fix_CPU0_microcode_on_resume.patch is a fix for  FS#42689  .
I tried to build linux-3.17.4 without fix_CPU0_microcode_on_resume.patch.
It seems to work fine, and I can't reproduce the bug  FS#42689  .

Does anyone meet the bug  FS#42689  on i686 machine?
Comment by Natrio (natrio) - Wednesday, 26 November 2014, 18:50 GMT
The 3.17.3 kernel, builded without this patch, wakes normally.

The 3.17.4-1-ARCH i686 (with patch) dies same like 3.17.3-1-ARCH i686, dis_ucode_ldr workaround (disable microcode loader) works too.

Maintainers, please, remove the fix_CPU0_microcode_on_resume.patch from i686 build, it is NOT works on i686 and kills i686 kernels after wake up.
Comment by Larry Johnson (keepitsimpleengineer) - Wednesday, 26 November 2014, 22:53 GMT
Seeing this with linux 3.17.4-1 and linux-ck.
Not seeing this on Manjaro Linux 3.17.0-1.
Lenovo S12 ~ cpu Intel® Atom™ CPU N270 @ 1.60GHz

Comment by jb (jb.1234abcd) - Thursday, 27 November 2014, 06:52 GMT
Linux myhost 3.17.4-1-ARCH #1 SMP PREEMPT Fri Nov 21 21:16:21 CET 2014 i686 GNU/Linux

Single CPU:
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Celeron(R) M processor 1.30GHz
stepping : 6
microcode : 0x17
cpu MHz : 1300.201
cache size : 1024 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr mce cx8 apic sep mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss tm pbe bts
bugs :
bogomips : 2601.75
clflush size : 64
cache_alignment : 64
address sizes : 32 bits physical, 32 bits virtual
power management:

No intel-ucode installed.
$ dmesg |grep microcode
[Thu Nov 27 07:30:58 2014] microcode: CPU0 sig=0x6d6, pf=0x20, revision=0x17
[Thu Nov 27 07:30:58 2014] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

No resume possible after suspend-to-ram.
Comment by Natrio (natrio) - Thursday, 27 November 2014, 07:01 GMT
jb, we need to add "dis_ucode_ldr" to kernel command line for really disabling the microcode loader on i686, regardless of intel-ucode installed or not.
It caused by fix_CPU0_microcode_on_resume.patch, added by Arch Linux maintainers to 3.17.3-1 and 3.17.4-1 kernels from unstable linux mainline.
Comment by jb (jb.1234abcd) - Thursday, 27 November 2014, 08:50 GMT
@Natrio
The dis_ucode_ldr is a debugging tool only, so it can not be used as a solution to a problem we face.
See the entire thread:
https://lkml.org/lkml/2014/9/5/148

This bug report
https://bugzilla.kernel.org/show_bug.cgi?id=88001
was closed, with a proposed patch
https://bugzilla.kernel.org/attachment.cgi?id=157641&action=diff
which was applied by Arch kernel maintainer.
It apparently solved some problems, but not the one we report.
Comment by Natrio (natrio) - Thursday, 27 November 2014, 09:02 GMT
@jb, you can also fallback to 3.17.2 or linux-lts, before removing this patch from i686 builds or replacing it by new this:
https://bugzilla.kernel.org/show_bug.cgi?id=88391#c20
Comment by Natrio (natrio) - Thursday, 27 November 2014, 09:04 GMT
And "dis_ucode_ldr" temporary workaround is proposed by author of patch.
Comment by SATO Tatsuya (tattsan) - Thursday, 27 November 2014, 11:23 GMT
I've built kernel 3.17.4 with the new patch https://bugzilla.kernel.org/show_bug.cgi?id=88391#c23 ,
and it seems to work fine. The author says the patch is dirty, and he'll clean it up.
Comment by Natrio (natrio) - Thursday, 27 November 2014, 12:37 GMT
>> Borislav Petkov 2014-11-27 12:09:20 UTC

> Ok, thanks for confirming.

> Just to clarify for the arch-linux kernel: the patch in there needs the
> #ifdef CONFIG_X86_64 around it as in comment #20. Btw, this patch is wrong:
> https://projects.archlinux.org/svntogit/packages.git/tree/trunk/fix_CPU0_microcode_on_resume.patch?h=packages/linux

> - it should be this one:
> http://git.kernel.org/tip/fb86b97300d930b57471068720c52bfa8622eab7

> Now, I've stopped it from going to -stable but since the fix for
> https://bugzilla.kernel.org/show_bug.cgi?id=88001 is still needed and if
> you guys want to have that addressed, I can give you the upstream commit
> which goes ontop of fb86b97300d930b57471068720c52bfa8622eab7 once I have
> tested it.

> Ask me if there still is misunderstanding.
> Thanks.
https://bugzilla.kernel.org/show_bug.cgi?id=88391#c25

Loading...