You are not logged in.
Hello,
my laptop locks up completely when I try to resume from suspend. This happens both when I close the lid or use systemctl suspend, the latter showing a frozen version of the last screen before suspend.
This problem only occured after an update to 3.17.1 and can be reproduced with every suspend-resume. The hardware is an Thinkpad X220i Tablet with an Intel(R) Core(TM) i3-2310M CPU @ 2.10GHz and 8Gb Ram.
The journalctl stops at the suspend and contains no errors.
Which other logs can I look into? (dmesg seems to only contain information from the last boot...)
Help is very much appreciated, since I am pretty much clueless. The suspend-resume has worked flawlessly before.
Greetings
Alcasa
Offline
Hey,
I know this isn't extremly helpful, but I have the same problem with my Thinkpad X220 Tablet Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz and 6Gb Ram.
Since I also hit a btrfs bug with read-only snapshots I'm using linux-lts for now, but I'd be really interested in solving this, too.
i'm sorry for my poor english wirting skills…
Offline
Fwiw: A related-sounding issue on a T43 Thinkpad: After Syyu-ing a few days ago (which included 3.17.1-1 and tp_smapi 0.41-55) found that suspend no longer worked properly. Specifically, after a suspend (invoked either via pm_suspend or via systemctl suspend) it would often resume almost immediately. Not every single time, but roughly 80% of the time. And the delay between suspend and "auto-resume" was variable too, most often nearly immediate (1-2 second), but sometimes 10 seconds or more. And occasionally it would stay suspended for hours.
I backed out the 3.17.1 kernel and tp_smapi 0.41-55 (downgraded to kernel 3.16.4-1 and tp_smapi 0.41.54) and am no longer seeing this behavior. So perhaps something fishy with the new kernel.
If you guys are able to reproduce this (i.e., if downgrading successfully works around your issues as well) please post those results here.
Last edited by grepfor (2014-10-27 18:52:26)
Offline
I'm having the same problem on a x220t with an i7-2620M. So has a friend with a x230t. Downgrading to 3.16.4 has solved the issue for both of us.
I couldn't find any more information, or what's the appropriate thing to do now. Should I report a bug against the `linux` Arch package? Or against the kernel directly?
>>> from __future__ import braces
File "<stdin>", line 1
SyntaxError: not a chance
Offline
It seems the bug is fixed in linux-mainline (from the AUR). I wonder what commit fixed it, but I don't have the time to bisect currently. There are about 11'000 commits between the two versions, i.e. compiling and testing about 14 times.
>>> from __future__ import braces
File "<stdin>", line 1
SyntaxError: not a chance
Offline
As far as I know, this bug only concerns Intel computers, because the problem is a BIOS low memory corruption:
Oct 29 08:09:12 ArchHost systemd-journal[196]: Runtime journal is using 8.0M (max allowed 294.1M, trying to leave 441.1M free of 2.8G available <E2><86>
Oct 29 08:09:12 ArchHost systemd-journal[196]: Runtime journal is using 8.0M (max allowed 294.1M, trying to leave 441.1M free of 2.8G available <E2><86>
Oct 29 08:09:12 ArchHost kernel: Initializing cgroup subsys cpuset
Oct 29 08:09:12 ArchHost kernel: Initializing cgroup subsys cpu
Oct 29 08:09:12 ArchHost kernel: Initializing cgroup subsys cpuacct
Oct 29 08:09:12 ArchHost kernel: Linux version 3.17.1-1-ARCH (nobody@var-lib-archbuild-testing-x86_64-tobias) (gcc version 4.9.1 20140903 (prerelease) (GCC
Oct 29 08:09:12 ArchHost kernel: Command line: BOOT_IMAGE=/vmlinuz-linux root=/dev/mapper/Foo rw cryptdevice=/dev/bar:cbar quiet
Oct 29 08:09:12 ArchHost kernel: e820: BIOS-provided physical RAM map:
Oct 29 08:09:12 ArchHost kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009d7ff] usable
Oct 29 08:09:12 ArchHost kernel: BIOS-e820: [mem 0x000000000009d800-0x000000000009ffff] reserved
Oct 29 08:09:12 ArchHost kernel: BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
Oct 29 08:09:12 ArchHost kernel: BIOS-e820: [mem 0x0000000000100000-0x000000001fffffff] usable
Oct 29 08:09:12 ArchHost kernel: BIOS-e820: [mem 0x0000000020000000-0x00000000201fffff] reserved
Oct 29 08:09:12 ArchHost kernel: BIOS-e820: [mem 0x0000000020200000-0x000000003fffffff] usable
Oct 29 08:09:12 ArchHost kernel: BIOS-e820: [mem 0x0000000040000000-0x00000000401fffff] reserved
Oct 29 08:09:12 ArchHost kernel: BIOS-e820: [mem 0x0000000040200000-0x00000000da52ffff] usable
Oct 29 08:09:12 ArchHost kernel: BIOS-e820: [mem 0x00000000da530000-0x00000000da572fff] ACPI NVS
Oct 29 08:09:12 ArchHost kernel: BIOS-e820: [mem 0x00000000da573000-0x00000000da7dcfff] usable
Oct 29 08:09:12 ArchHost kernel: BIOS-e820: [mem 0x00000000da7dd000-0x00000000da966fff] reserved
Oct 29 08:09:12 ArchHost kernel: BIOS-e820: [mem 0x00000000da967000-0x00000000dacebfff] usable
Oct 29 08:09:12 ArchHost kernel: BIOS-e820: [mem 0x00000000dacec000-0x00000000dad67fff] reserved
Oct 29 08:09:12 ArchHost kernel: BIOS-e820: [mem 0x00000000dad68000-0x00000000dafe7fff] ACPI NVS
Oct 29 08:09:12 ArchHost kernel: BIOS-e820: [mem 0x00000000dafe8000-0x00000000daffffff] ACPI data
Oct 29 08:09:12 ArchHost kernel: BIOS-e820: [mem 0x00000000db800000-0x00000000df9fffff] reserved
Oct 29 08:09:12 ArchHost kernel: BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
Oct 29 08:09:12 ArchHost kernel: BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
Oct 29 08:09:12 ArchHost kernel: BIOS-e820: [mem 0x00000000fed00000-0x00000000fed03fff] reserved
Oct 29 08:09:12 ArchHost kernel: BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
Oct 29 08:09:12 ArchHost kernel: BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
Oct 29 08:09:12 ArchHost kernel: BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
Oct 29 08:09:12 ArchHost kernel: BIOS-e820: [mem 0x0000000100000000-0x000000019fdfffff] usable
Oct 29 08:09:12 ArchHost kernel: NX (Execute Disable) protection: active
Oct 29 08:09:12 ArchHost kernel: SMBIOS 2.7 present.
Oct 29 08:09:12 ArchHost kernel: DMI: CLEVO CO. W240HU/W250HUQ /W240HU/W250HUQ , BIOS 4.6.4 08/09/
Oct 29 08:09:12 ArchHost kernel: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
Oct 29 08:09:12 ArchHost kernel: e820: remove [mem 0x000a0000-0x000fffff] usable
Oct 29 08:09:12 ArchHost kernel: AGP: No AGP bridge found
Oct 29 08:09:12 ArchHost kernel: e820: last_pfn = 0x19fe00 max_arch_pfn = 0x400000000
Oct 29 08:09:12 ArchHost kernel: MTRR default type: uncachable
Oct 29 08:09:12 ArchHost kernel: MTRR fixed ranges enabled:
Oct 29 08:09:12 ArchHost kernel: 00000-9FFFF write-back
Oct 29 08:09:12 ArchHost kernel: A0000-BFFFF uncachable
Oct 29 08:09:12 ArchHost kernel: C0000-CFFFF write-protect
Oct 29 08:09:12 ArchHost kernel: D0000-E7FFF uncachable
Oct 29 08:09:12 ArchHost kernel: E8000-FFFFF write-protect
Oct 29 08:09:12 ArchHost kernel: MTRR variable ranges enabled:
Oct 29 08:09:12 ArchHost kernel: 0 base 000000000 mask F00000000 write-back
Oct 29 08:09:12 ArchHost kernel: 1 base 100000000 mask F80000000 write-back
Oct 29 08:09:12 ArchHost kernel: 2 base 180000000 mask FE0000000 write-back
Oct 29 08:09:12 ArchHost kernel: 3 base 0DB800000 mask FFF800000 uncachable
Oct 29 08:09:12 ArchHost kernel: 4 base 0DC000000 mask FFC000000 uncachable
Oct 29 08:09:12 ArchHost kernel: 5 base 0E0000000 mask FE0000000 uncachable
Oct 29 08:09:12 ArchHost kernel: 6 base 19FE00000 mask FFFE00000 uncachable
Oct 29 08:09:12 ArchHost kernel: 7 disabled
Oct 29 08:09:12 ArchHost kernel: 8 disabled
Oct 29 08:09:12 ArchHost kernel: 9 disabled
Oct 29 08:09:12 ArchHost kernel: x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
Oct 29 08:09:12 ArchHost kernel: e820: update [mem 0xdb800000-0xffffffff] usable ==> reserved
Oct 29 08:09:12 ArchHost kernel: e820: last_pfn = 0xdacec max_arch_pfn = 0x400000000
Oct 29 08:09:12 ArchHost kernel: found SMP MP-table at [mem 0x000fcde0-0x000fcdef] mapped at [ffff8800000fcde0]
Oct 29 08:09:12 ArchHost kernel: Scanning 1 areas for low memory corruption
Oct 29 08:09:12 ArchHost kernel: Base memory trampoline at [ffff880000097000] 97000 size 24576
Oct 29 08:09:12 ArchHost kernel: reserving inaccessible SNB gfx pages
Oct 29 08:09:12 ArchHost kernel: init_memory_mapping: [mem 0x00000000-0x000fffff]
Oct 29 08:09:12 ArchHost kernel: [mem 0x00000000-0x000fffff] page 4k
Oct 29 08:09:12 ArchHost kernel: BRK [0x01b2f000, 0x01b2ffff] PGTABLE
Oct 29 08:09:12 ArchHost kernel: BRK [0x01b30000, 0x01b30fff] PGTABLE
Oct 29 08:09:12 ArchHost kernel: BRK [0x01b31000, 0x01b31fff] PGTABLE
Oct 29 08:09:12 ArchHost kernel: init_memory_mapping: [mem 0x19fc00000-0x19fdfffff]
Oct 29 08:09:12 ArchHost kernel: [mem 0x19fc00000-0x19fdfffff] page 2M
Oct 29 08:09:12 ArchHost kernel: BRK [0x01b32000, 0x01b32fff] PGTABLE
Oct 29 08:09:12 ArchHost kernel: init_memory_mapping: [mem 0x19c000000-0x19fbfffff]
Oct 29 08:09:12 ArchHost kernel: [mem 0x19c000000-0x19fbfffff] page 2M
Oct 29 08:09:12 ArchHost kernel: init_memory_mapping: [mem 0x180000000-0x19bffffff]
Oct 29 08:09:12 ArchHost kernel: [mem 0x180000000-0x19bffffff] page 2M
Oct 29 08:09:12 ArchHost kernel: init_memory_mapping: [mem 0x00100000-0x1fffffff]
Oct 29 08:09:12 ArchHost kernel: [mem 0x00100000-0x001fffff] page 4k
Oct 29 08:09:12 ArchHost kernel: [mem 0x00200000-0x1fffffff] page 2M
Oct 29 08:09:12 ArchHost kernel: init_memory_mapping: [mem 0x20200000-0x3fffffff]
Oct 29 08:09:12 ArchHost kernel: [mem 0x20200000-0x3fffffff] page 2M
Oct 29 08:09:12 ArchHost kernel: init_memory_mapping: [mem 0x40200000-0xda52ffff]
Oct 29 08:09:12 ArchHost kernel: [mem 0x40200000-0xda3fffff] page 2M
Oct 29 08:09:12 ArchHost kernel: [mem 0xda400000-0xda52ffff] page 4k
Oct 29 08:09:12 ArchHost kernel: BRK [0x01b33000, 0x01b33fff] PGTABLE
Oct 29 08:09:12 ArchHost kernel: BRK [0x01b34000, 0x01b34fff] PGTABLE
Oct 29 08:09:12 ArchHost kernel: init_memory_mapping: [mem 0xda573000-0xda7dcfff]
Oct 29 08:09:12 ArchHost kernel: [mem 0xda573000-0xda7dcfff] page 4k
Oct 29 08:09:12 ArchHost kernel: init_memory_mapping: [mem 0xda967000-0xdacebfff]
Oct 29 08:09:12 ArchHost kernel: [mem 0xda967000-0xda9fffff] page 4k
Oct 29 08:09:12 ArchHost kernel: [mem 0xdaa00000-0xdabfffff] page 2M
Oct 29 08:09:12 ArchHost kernel: [mem 0xdac00000-0xdacebfff] page 4k
Oct 29 08:09:12 ArchHost kernel: init_memory_mapping: [mem 0x100000000-0x17fffffff]
Oct 29 08:09:12 ArchHost kernel: [mem 0x100000000-0x17fffffff] page 2M
Oct 29 08:09:12 ArchHost kernel: RAMDISK: [mem 0x37446000-0x37a1afff]This problem has been since 3.17 was released.
----- Think out of the Box. ------
Archer since 2010.
My projects: http://github.com/kinokoio
Offline
FYI: I filed an Arch bug report on this, summarizing all your inputs and referencing this thread:
Offline
Hi,
I have the same problem on a x230t with i5-3320M CPU @ 2.60GHz and 16GB ram. Also the suspend to ram worked without issues before. Trying to automatically dump the dmesg into a file after resume with
dmesg > dmesg_before; echo mem > /sys/power/state; dmesg > dmesg_after didn't work (following this page).
At the moment I have no time to downgrade or other workarounds, so I can't reproduce this. Also thanks for posting the bug report.
Offline
Possible solution/evasion: Before suspending lower the RAM Memory ~300MB. I hibernated it three times with that setup for more than thirty minutes and it didn't freeze.
FYI: I filed an Arch bug report on this, summarizing all your inputs and referencing this thread:
Thanks for the bug report. My CPU is an Intel(R) Pentium(R) CPU B960 (laptop). Hope that helps too.
----- Think out of the Box. ------
Archer since 2010.
My projects: http://github.com/kinokoio
Offline
http://www.spinics.net/lists/linux-input/msg33611.html see here, linux-input should probably fix this as it affects more people than just me ![]()
Offline
Fellow-sufferers of this issue: If you have a login on the Arch bug tracker, you can "vote" for this bug, which presumably indicates to the devs the amount of interest in getting it resolved. I've no clue as to how much effect the vote value actually has, but it can't hurt. Just fyi.
The bug report URL is shown in message #7 above.
Offline
3.17.2 is out in packaged form, perusing the commits I see this:
http://git.kernel.org/cgit/linux/kernel … 3fdaba0be4
Someone try an upgrade, see if it's fixed maybe?
Offline
I can confirm that updating to 3.17.2 solves this issue.
Offline
The upgrade to 3.17.2 solved the issue for me, too. Thanks!
Offline
Just fyi: 3.17.2-1 does not solve the problem described in message #3. (However, the #3 problem is symptomatically somewhat different than the problem most others are describing in this thread, which probably means they are distinct issues.)
Offline
Upgrading to kernel 3.17.4-1 did not solve the issue on my dell 910 netbook with Intel Atom CPU.
Offline
On a
* Lenovo IdeaPad S10-2 (2957), Intel Atom CPU N270 and on a
* Dell Vostro 1220, Intel Core 2 Duo
the issue appeared after upgrading from Kernel 3.17-2 to 3.17-3. Upgrading to 3.17-4 did not solve the problem.
Last edited by HaCeMei (2014-12-01 06:30:10)
No new thing under the sun
Offline
Upgrading to 3.17.4-1 did not solve the problem on my Thinkpad X200T.
Offline
I upgraded from 3.16.x to 3.17.4-1 and that's when this problem started for me.
Offline
I am affected as well. Journalctl shows no errors, reproducible every time. After waking up from suspend, screen remains blank. Computer cannot be pinged or shutdown opening a terminal and typing blindly. It occured after the updgrade to 3.17.1, upgrading to 3.17.2 did not solve the issue for me. Hardware is a Samsung N130 Laptop with an Intel(R) Atom(TM) CPU N270 @ 1.60GHz. I migrated to the lts kernel as a workaround, as I use suspend everyday and cannot live without it.
Offline
Any helps?
Offline
I have been having a similar issue with my Toshiba NB505.
However, I did take notice that I disabled my network manager daemon, it will resume from sleep without a problem.
Enabling NetworkManager or Wicd and then putting the laptop to sleep via pm-utils or systemctl results in the computer not waking correctly. Journalctl doesn't report any issues either.
Though I do think this is a upstream kernel issue. Xubuntu 14.10 with the 3.16.0 generic kernel results in the same issue. With Debian Wheezy with 3.2.63 the issue doesn't exist.
Does this work for anyone else?
--- Edit ---
Using netctl and wifi-menu works okay. No sleeping issues there.
Last edited by roma0104 (2014-12-12 22:50:03)
Offline
Problem solved after upgrading to 3.17.6 on Thinkpad X200T.
Offline
Problem solved after upgrading to 3.17.6 on Thinkpad X200T.
Same here, cf. #17
No new thing under the sun
Offline
sharpevo wrote:Problem solved after upgrading to 3.17.6 on Thinkpad X200T.
Same here, cf. #17
Same same, upgrading from 3.17.4-1 to 3.17.6-1 solved this issue. Looks like this one's blown over.
Offline