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
Opened by Natrio (natrio) - Monday, 17 November 2014, 17:39 GMT
Last edited by Evangelos Foutras (foutrelis) - Sunday, 07 December 2014, 08:16 GMT
|
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
Sunday, 07 December 2014, 08:16 GMT
Reason for closing: Fixed
Additional comments about closing: linux 3.17.5-1
It worked fine with 3.17.2-1 also.
VGA x300 (rv370) with radeon driver.
Motherboard Asus P5P43TD PRO
Intel Core i3-3110M
Intel Corporation 3rd Gen Core processor Graphics Controller
Kernel 3.17.2 works fine.
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.
I tested linux 3.17.4-1 (testing repository), but the problem was not solved.
https://bugzilla.kernel.org/show_bug.cgi?id=88391
I cannot help with a bisect after reinstalling as 64 bit, and I don't have another hard-drive lying around unfortunately.
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
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.
> 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
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#42689on i686 machine?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.
Not seeing this on Manjaro Linux 3.17.0-1.
Lenovo S12 ~ cpu Intel® Atom™ CPU N270 @ 1.60GHz
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.
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.
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.
https://bugzilla.kernel.org/show_bug.cgi?id=88391#c20
and it seems to work fine. The author says the patch is dirty, and he'll clean it up.
> 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