Arch Linux

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.

It seems to be i686 build of linux-3.17.3 can't wake after suspend on any tested machines.

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

Same issue
Intel Core i3-3110M
Intel Corporation 3rd Gen Core processor Graphics Controller

Also have this issue on hp6820s 32bit. Switch back to 3.17.2-1

Same issue with an eeepc 1005HA (32 bits).
Kernel 3.17.2 works fine.

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.

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.

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.

Same issue, i686 on Thinkpad X40, Pentium M.

I tested linux 3.17.4-1 (testing repository), but the problem was not solved.

Can anyone to do git bisect for this bug?
https://bugzilla.kernel.org/show_bug.cgi?id=88391

Same here, i686 on Thinkpad X60

eeePC 901, same issue, 3.17.2-1-ARCH resumes from suspend but 3.17.3-1-ARCH does not.

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.

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

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.

>> 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

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?

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.

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

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.

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.

@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.

@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

And "dis_ucode_ldr" temporary workaround is proposed by author of patch.

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.

>> 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