Arch Linux

yourself

Member

Registered: 2008-10-23

Posts: 120

Re: [SOLVED]Linux3.4 broke resume/suspend some of the times in Lenovo T420

If you use xfce and xfce4-power-manager then you don't need acpid at all. The power manager is more than capable to handle everything you may need, from the press of the power button to the closure of the lid. Even the hibernate button works without a hitch.

Well, should I just do away with acpid? Because I've been running it for years!!

And by the way, I had not seen this:

Warning: Please note that desktop environments such as GNOME tend to have their own means of handling ACPI events, independent of acpid. Running both systems at the same time may lead to unexpected behaviour

Maybe that's the source of my problems!?

Last edited by yourself (2012-07-28 18:30:41)

dschrute

Member

From: NJ, USA

Registered: 2007-04-09

Posts: 183

Re: [SOLVED]Linux3.4 broke resume/suspend some of the times in Lenovo T420

Well, acpid may not be necessary, but removing it hasn't fixed the issue for me...I just had the problem after uninstalling acpid.  I really thought that was it for me.  Oh well will keep looking.

After reading or re-reading a few other wiki pages I do have a better idea of the overall setup.  I may reinstall acpid and tweak things a bit more so that it doesn't conflict with what XFCE is doing, that way I I was working without X ( I do sometimes ) or not in XFCE (also sometimes ) I'd still have some of the same options for power management.

Essl

Member

Registered: 2012-07-15

Posts: 27

Re: [SOLVED]Linux3.4 broke resume/suspend some of the times in Lenovo T420

sudo pacman -R acpid
Password:
error: target not found: acpid

Wouldn't explain the problem for me...

yourself

Member

Registered: 2008-10-23

Posts: 120

Re: [SOLVED]Linux3.4 broke resume/suspend some of the times in Lenovo T420

sudo pacman -R acpid
Password:
error: target not found: acpid

Wouldn't explain the problem for me...

Well, acpid may not be necessary, but removing it hasn't fixed the issue for me...I just had the problem after uninstalling acpid.  I really thought that was it for me.  Oh well will keep looking.

Drat! I really thought we had something there..... Anyway, since I have this brand new SUSPEND_MODULES="iwlwifi uhci_hcd button" in my /etc/pm/config.d/modules, I'll keep closing the lid until it happens to me, too (unless, of course, this is the solution!!)...

In any case, when I said that we should look into the ACPI subsystem, I wasn't really referring to acpid (although that *would* have been a nice and clean solution, dammit!!!) but to find out what extra (or less) is happening when the suspend is initiated by an ACPI event such as closing the lid...

Essl

Member

Registered: 2012-07-15

Posts: 27

Re: [SOLVED]Linux3.4 broke resume/suspend some of the times in Lenovo T420

So that basically means the problem is most likely somewhere in Thinkpad-acpi, which as I understand it has become part of the kernel. Maybe we should file a bug report?

edit: this would make sense as well since you said the problem only occured after updating to a certain kernel version. Maybe we should look at the differences in thinkpad-acpi between the non-offending and offending kernel versions?

Last edited by Essl (2012-07-29 15:49:55)

dschrute

Member

From: NJ, USA

Registered: 2007-04-09

Posts: 183

Re: [SOLVED]Linux3.4 broke resume/suspend some of the times in Lenovo T420

I think it's a good idea to look closer at acpi.  I found the following on the XFCE mailing list after googling a little, which is similar to the issue we've been having, and it also points towards acpi :
http://mail.xfce.org/pipermail/xfce/201 … 26649.html

In short, someone has having issues suspending from XFCE when closing the lid and noticed the value of /proc/acpi/button/lid/LID0/state was incorrect before a unsuccessful attempt.  So I'll be checking it each time before I suspend, just to see what it looks like, and then what happens.

yourself

Member

Registered: 2008-10-23

Posts: 120

Re: [SOLVED]Linux3.4 broke resume/suspend some of the times in Lenovo T420

Ok, so it happened again, as you all said, without acpid, so no dice!

In short, someone has having issues suspending from XFCE when closing the lid and noticed the value of /proc/acpi/button/lid/LID0/state was incorrect before a unsuccessful attempt.  So I'll be checking it each time before I suspend, just to see what it looks like, and then what happens.

Well, it's a very nice idea but I think that is related to the reboot/suspend issue. It seems something in the kernel's ACPI susbystem gets stuck (and continues in the event of reboot, where the actual suspend takes place) so the value in /proc/acpi/button/lid/LID0/state doesn't get updated. It is my impression that if you check it just before the actual suspend when rebooting, you'll see that it points to 'closed' even though it is very clearly open.

Oh, and another thing! Now that acpid was not running, the sleep led did not start blinking. It never went on in the first place (it might be the same problem or a related one)....

Once again, the kernel log stops at

Jul 29 22:05:22 localhost kernel: [ 6668.627470] PM: Syncing filesystems ... done.
Jul 29 22:05:22 localhost kernel: [ 6668.629261] PM: Preparing system for mem sleep

Note that when this issue occurs and I open the lid, ps -ax shows that s2ram --force is running but is in state (S)leeping. So it seems that s2ram did make a blocking call or something and the kernel never returned. Furthermore, an

 # echo "mem" > /sys/power/state

returns "Device busy" so something *must* be stuck (possible race condition?) in the kernel.

I'm really desparate. Maybe we should file a bug report in the kernel mailing list.

There are two remaining things to test:
1. Downgrade to kernel 3.1.9 (this is so way back, it SHOULD be fine, otherwise it is something else rather than the kernel).
2. Blacklist i915 and disable hardware accel, just use plain vesa.

I'll report back what happens....

goran'agar

Member

From: Nothern Italy

Registered: 2009-05-19

Posts: 171

Re: [SOLVED]Linux3.4 broke resume/suspend some of the times in Lenovo T420

Ok, so it happened again, as you all said, without acpid, so no dice!

In short, someone has having issues suspending from XFCE when closing the lid and noticed the value of /proc/acpi/button/lid/LID0/state was incorrect before a unsuccessful attempt.  So I'll be checking it each time before I suspend, just to see what it looks like, and then what happens.

Well, it's a very nice idea but I think that is related to the reboot/suspend issue. It seems something in the kernel's ACPI susbystem gets stuck (and continues in the event of reboot, where the actual suspend takes place) so the value in /proc/acpi/button/lid/LID0/state doesn't get updated. It is my impression that if you check it just before the actual suspend when rebooting, you'll see that it points to 'closed' even though it is very clearly open.

Oh, and another thing! Now that acpid was not running, the sleep led did not start blinking. It never went on in the first place (it might be the same problem or a related one)....

Once again, the kernel log stops at

Jul 29 22:05:22 localhost kernel: [ 6668.627470] PM: Syncing filesystems ... done.
Jul 29 22:05:22 localhost kernel: [ 6668.629261] PM: Preparing system for mem sleep

Note that when this issue occurs and I open the lid, ps -ax shows that s2ram --force is running but is in state (S)leeping. So it seems that s2ram did make a blocking call or something and the kernel never returned. Furthermore, an

 # echo "mem" > /sys/power/state

returns "Device busy" so something *must* be stuck (possible race condition?) in the kernel.

I'm really desparate. Maybe we should file a bug report in the kernel mailing list.

There are two remaining things to test:
1. Downgrade to kernel 3.1.9 (this is so way back, it SHOULD be fine, otherwise it is something else rather than the kernel).
2. Blacklist i915 and disable hardware accel, just use plain vesa.

I'll report back what happens....

You can exec a:

strace -p <pid_of_s2ram>

to see which system call is in execution. Also, the dmesg log should tell you what's happening, the kernel log is worth nothing in this case.

---

Sony Vaio VPCM13M1E  - Arch Linux - LXDE

dschrute

Member

From: NJ, USA

Registered: 2007-04-09

Posts: 183

Re: [SOLVED]Linux3.4 broke resume/suspend some of the times in Lenovo T420

Well, it's a very nice idea but I think that is related to the reboot/suspend issue.

Yeah, not such a nice idea anyway.  /proc/acpi/button/lid/LID0/state showed the correct status ( open ) and I got a failed suspend when closing the lid.  I'm done with my brilliant guess work :-\

Essl

Member

Registered: 2012-07-15

Posts: 27

Re: [SOLVED]Linux3.4 broke resume/suspend some of the times in Lenovo T420

Maybe we should just anonymously send a bunch of Thinkpads to kernel developers.

I'm interested to see what the downgrade will do, I have high hopes for this one.

yourself

Member

Registered: 2008-10-23

Posts: 120

Re: [SOLVED]Linux3.4 broke resume/suspend some of the times in Lenovo T420

You can exec a:

strace -p <pid_of_s2ram>

to see which system call is in execution. Also, the dmesg log should tell you what's happening, the kernel log is worth nothing in this case.

Nice idea, I'll try it next time it happens (since I haven't got around to downgrade yet, it should be pretty soon :-( .....)

yourself

Member

Registered: 2008-10-23

Posts: 120

Re: [SOLVED]Linux3.4 broke resume/suspend some of the times in Lenovo T420

Maybe we should just anonymously send a bunch of Thinkpads to kernel developers.
I'm interested to see what the downgrade will do, I have high hopes for this one.

To tell you the truth, I don't because a while ago I downgraded to 3.3.8 and had it happen again. But maybe 3.1.x will be different, who knows?

juchem

Member

Registered: 2012-07-30

Posts: 3

Re: [SOLVED]Linux3.4 broke resume/suspend some of the times in Lenovo T420

I have 3.2 on my Debian Unstable + Gnome3 and suspend hangs. I get a blank console screen and keyboard seems to stop responding.
I know this is an Arch Linux forum but that's the most useful post I found about this problem, I hope you guys don't mind.
Right now I installled 3.4-trunk-rt from the Experimental branch and will try it, who knows. I'm at the point of getting myself a voodoo charm to see if it helps.

yourself

Member

Registered: 2008-10-23

Posts: 120

Re: [SOLVED]Linux3.4 broke resume/suspend some of the times in Lenovo T420

Ok, here's some fresh and useful-looking information.
Standard configuration (linux-3.4.6), happened again.

So I logged in, found the pid of the 's2ram --force' command (906) and ran:

root /home/yourself # strace -p 906

My system immediately suspended! When I resumed it, i saw this:

root /home/yourself # strace -p 906
Process 906 attached
close(4)                               = 0
munmap(0x7fade611c000, 4096)           = 0
write(1,"KMS graphics driver is in use, s"..., 48) = 48
exit_group(0)                          = ?
+++ exited with 0 +++
root /home/yourself # 

I've managed to capture the complete dmesg ouput of an ok sequence of suspend/resume and a not ok one and the complete dmesg (with timestamps) after the 2nd suspend. Please notice that the kernel continues a "correct" suspend cycle (it continues with "Freezing user space processes ..." after the "PM: Preparing system for mem sleep" - also notice the difference in the timestamps: 13436.488518 and then 13921.233407!) so my intuition seems correct: something is blocking the kernel. 

Maybe it's i915? This "KMS graphics driver is in use" is *very* suspicious. And *WHY* does it suspend after attaching to s2ram??

Do you feel that this is sufficient data to file a bug report against the i915 module? Or maybe it's the drm_kms_helper module, which is used by i915, according to lsmod.

Normal suspend: https://dl.dropbox.com/u/63420/dmesg.ok.txt
Borked suspend: https://dl.dropbox.com/u/63420/dmesg.notok.txt
Borked suspend + suspend after strace -p 906: https://dl.dropbox.com/u/63420/dmesg.no … uspend.txt

Last edited by yourself (2012-07-30 21:25:16)

yourself

Member

Registered: 2008-10-23

Posts: 120

Re: [SOLVED]Linux3.4 broke resume/suspend some of the times in Lenovo T420

I have 3.2 on my Debian Unstable + Gnome3 and suspend hangs. I get a blank console screen and keyboard seems to stop responding.
I know this is an Arch Linux forum but that's the most useful post I found about this problem, I hope you guys don't mind.
Right now I installled 3.4-trunk-rt from the Experimental branch and will try it, who knows. I'm at the point of getting myself a voodoo charm to see if it helps.

Hello juchem.

Of course we don't mind, you're more than welcome!

From your description, though, it seems that you are experiencing something else, not related to our problem. Our laptops don't hang, they just don't suspend correctly (they consume a lot of power for suspended state) and resume with something weird having taken place which kills our X session. The suspend procedure takes place correctly after some specific events take place.

juchem

Member

Registered: 2012-07-30

Posts: 3

Re: [SOLVED]Linux3.4 broke resume/suspend some of the times in Lenovo T420

I messed up when I expressed myself. I'm having exactly what you described in the first post. Have you guys looked at this thread?
http://forums.fedoraforum.org/showthread.php?t=275588
There's some info on getting thinkpad_acpi and the fan working and some other info related to T420. It may help.

I also experienced a hang when booting on the "Waiting for /dev to be fully populated..." step. Not sure but it could be related (some driver deadlocking?). This won't happen anymore, though, after I: disabled virtualization and virtualization IO support in the BIOS; uninstalled acpid; and updated to the "-rt" (PREEMPT_RT) flavor of the kernel. I didn't take the time to isolate the solution (it could even be something else, I've done so much stuff in the last couple days that I don't know anymore when exactly the issue went away), but since it's working I'm not feeling like going back to diagnose. I could though if it would help with the suspend issues.

dwnomad

Member

Registered: 2012-07-12

Posts: 4

Re: [SOLVED]Linux3.4 broke resume/suspend some of the times in Lenovo T420

It's not just a Thinkpad issue, as I've had the same exact problem with my Asus Eee netbook. It's happened to me using LXDE or Openbox with XFCE4 Power Manager and also with KDE. I've even tried Fedora 17 LXDE (3.4.x) and Lubuntu 12.04 (3.3.x) and both had the same issue. However, CrunchBang 10 with backports (3.2.0) is working fine, although it's quite annoying to have such old of software.

For those of you trying kernel downgrades, you could just install the lts kernel, currently at 3.0.38-1 to rule out the kernel?

Unfortunately I'm too busy this summer to try to track down the issue and this problem was causing me to lose a little too much work.

yourself

Member

Registered: 2008-10-23

Posts: 120

Re: [SOLVED]Linux3.4 broke resume/suspend some of the times in Lenovo T420

So, I've tried with 3.0.38, excatly the same thing happened.

One other thing is that during the (failed) suspend procedure, X segfaults and this is why we all get dropped back to our display managers. Here's the last lines of my X log:

[  6095.260] (II) AIGLX: Suspending AIGLX clients for VT switch
[  6116.547] (II) AIGLX: Resuming AIGLX clients after VT switch
[  6118.053] (II) intel(0): EDID vendor "LGD", prod id 738
[  6118.054] (II) intel(0): Printing DDC gathered Modelines:
[  6118.054] (II) intel(0): Modeline "1600x900"x0.0   96.00  1600 1648 1680 1728  900 903 908 926 -hsync -vsync (55.6 kHz eP)
[  6120.409] (--) synaptics: SynPS/2 Synaptics TouchPad: touchpad found
[  7078.130] (II) AIGLX: Suspending AIGLX clients for VT switch
[  7081.997] (II) AIGLX: Resuming AIGLX clients after VT switch
[  7082.050] (II) intel(0): EDID vendor "LGD", prod id 738
[  7082.050] (II) intel(0): Printing DDC gathered Modelines:
[  7082.050] (II) intel(0): Modeline "1600x900"x0.0   96.00  1600 1648 1680 1728  900 903 908 926 -hsync -vsync (55.6 kHz eP)
[  7085.063] (--) synaptics: SynPS/2 Synaptics TouchPad: touchpad found
[  8611.400] 
[  8611.400] Backtrace:
[  8611.404] 0: /usr/bin/X (xorg_backtrace+0x36) [0x560306]
[  8611.404] 1: /usr/bin/X (0x400000+0x164039) [0x564039]
[  8611.404] 2: /usr/lib/libpthread.so.0 (0x7fe2ecf1c000+0xf170) [0x7fe2ecf2b170]
[  8611.404] 3: /usr/bin/X (XIChangeDeviceProperty+0x1b8) [0x502d58]
[  8611.404] 4: /usr/bin/X (DisableDevice+0x20f) [0x42d8ff]
[  8611.404] 5: /usr/bin/X (xf86Wakeup+0x494) [0x46fa44]
[  8611.404] 6: /usr/bin/X (WakeupHandler+0x6b) [0x43848b]
[  8611.404] 7: /usr/bin/X (WaitForSomething+0x1a4) [0x55d744]
[  8611.404] 8: /usr/bin/X (0x400000+0x34281) [0x434281]
[  8611.404] 9: /usr/bin/X (0x400000+0x23615) [0x423615]
[  8611.404] 10: /usr/lib/libc.so.6 (__libc_start_main+0xf5) [0x7fe2ebdcb725]
[  8611.404] 11: /usr/bin/X (0x400000+0x238ed) [0x4238ed]
[  8611.404] 
[  8611.405] Segmentation fault at address 0x11
[  8611.405] 
Fatal server error:
[  8611.405] Caught signal 11 (Segmentation fault). Server aborting
[  8611.405] 
[  8611.405] 
Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
[  8611.405] Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[  8611.405] 
[  8611.720] (II) evdev: ThinkPad Extra Buttons: Close
[  8611.720] (II) UnloadModule: "evdev"
[  8612.040] (II) evdev: TPPS/2 IBM TrackPoint: Close
[  8612.040] (II) UnloadModule: "evdev"

Furthermore, I've started stracing the s2ram procedure, and this is a normal one:

execve("/usr/sbin/s2ram", ["s2ram", "--force"], [/* 41 vars */]) = 0
brk(0)                                  = 0xfd2000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8e7af86000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=212953, ...}) = 0
mmap(NULL, 212953, PROT_READ, MAP_PRIVATE, 4, 0) = 0x7f8e7af52000
close(4)                                = 0
open("/usr/lib/libx86.so.1", O_RDONLY|O_CLOEXEC) = 4
read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20x\0\0\0\0\0\0"..., 832) = 832
fstat(4, {st_mode=S_IFREG|0755, st_size=135568, ...}) = 0
mmap(NULL, 2233888, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0x7f8e7ab44000
mprotect(0x7f8e7ab64000, 2093056, PROT_NONE) = 0
mmap(0x7f8e7ad63000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x1f000) = 0x7f8e7ad63000
mmap(0x7f8e7ad65000, 1568, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f8e7ad65000
close(4)                                = 0
open("/usr/lib/libpci.so.3", O_RDONLY|O_CLOEXEC) = 4
read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`#\0\0\0\0\0\0"..., 832) = 832
fstat(4, {st_mode=S_IFREG|0644, st_size=48320, ...}) = 0
mmap(NULL, 2143376, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0x7f8e7a938000
mprotect(0x7f8e7a943000, 2093056, PROT_NONE) = 0
mmap(0x7f8e7ab42000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0xa000) = 0x7f8e7ab42000
close(4)                                = 0
open("/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 4
read(4, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0000\30\2\0\0\0\0\0"..., 832) = 832
fstat(4, {st_mode=S_IFREG|0755, st_size=1997041, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8e7af51000
mmap(NULL, 3816528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0x7f8e7a594000
mprotect(0x7f8e7a72f000, 2093056, PROT_NONE) = 0
mmap(0x7f8e7a92e000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x19a000) = 0x7f8e7a92e000
mmap(0x7f8e7a934000, 15440, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f8e7a934000
close(4)                                = 0
open("/usr/lib/libresolv.so.2", O_RDONLY|O_CLOEXEC) = 4
read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200:\0\0\0\0\0\0"..., 832) = 832
fstat(4, {st_mode=S_IFREG|0755, st_size=84808, ...}) = 0
mmap(NULL, 2189928, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0x7f8e7a37d000
mprotect(0x7f8e7a390000, 2097152, PROT_NONE) = 0
mmap(0x7f8e7a590000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x13000) = 0x7f8e7a590000
mmap(0x7f8e7a592000, 6760, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f8e7a592000
close(4)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8e7af50000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8e7af4f000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8e7af4e000
arch_prctl(ARCH_SET_FS, 0x7f8e7af4f700) = 0
mprotect(0x7f8e7a92e000, 16384, PROT_READ) = 0
mprotect(0x7f8e7a590000, 4096, PROT_READ) = 0
mprotect(0x7f8e7ab42000, 4096, PROT_READ) = 0
mprotect(0x60a000, 4096, PROT_READ)     = 0
mprotect(0x7f8e7af87000, 4096, PROT_READ) = 0
munmap(0x7f8e7af52000, 212953)          = 0
openat(AT_FDCWD, "/sys/class/drm", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4
brk(0)                                  = 0xfd2000
brk(0xffb000)                           = 0xffb000
getdents(4, /* 13 entries */, 32768)    = 424
brk(0xff3000)                           = 0xff3000
close(4)                                = 0
fstat(1, {st_mode=S_IFREG|0644, st_size=3843, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8e7af85000
open("/sys/power/state", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8e7af84000
write(4, "mem", 3)                      = 3
close(4)                                = 0
munmap(0x7f8e7af84000, 4096)            = 0
write(1, "KMS graphics driver is in use, s"..., 48KMS graphics driver is in use, skipping quirks.
) = 48
exit_group(0)                           = ?
+++ exited with 0 +++

Compare it with this, which takes place after a borked suspend (and suspends the machine):  (906 is the pid of "s2ram --force")

root /home/yourself # strace -p 906
Process 906 attached
-------------------- SMALL DELAY (1-2 sec), SCREEN GOES BLANK HERE -------------------
close(4)                               = 0
munmap(0x7fade611c000, 4096)           = 0
write(1,"KMS graphics driver is in use, s"..., 48) = 48
exit_group(0)                          = ?
+++ exited with 0 +++
root /home/yourself # 

I believe it is obvious that s2ram cannot write "mem" to /sys/power/state (I'm keeping straces of s2ram's operations, I'll post the full strace of a borked one, but I think that it will keep trying to write "mem" in /sys/power/state.

Also, this seems to happen right after I have clocked 24 hours uptime.

goran'agar

Member

From: Nothern Italy

Registered: 2009-05-19

Posts: 171

Re: [SOLVED]Linux3.4 broke resume/suspend some of the times in Lenovo T420

Can you try using s2ram with the s3_bios trick ?

---

Sony Vaio VPCM13M1E  - Arch Linux - LXDE

yourself

Member

Registered: 2008-10-23

Posts: 120

Re: [SOLVED]Linux3.4 broke resume/suspend some of the times in Lenovo T420

Can you try using s2ram with the s3_bios trick ?

How do I do that? Because s2ram says specifically that because KMS is in use, it is skipping quirks.

yourself

Member

Registered: 2008-10-23

Posts: 120

Re: [SOLVED]Linux3.4 broke resume/suspend some of the times in Lenovo T420

Ok, I have manually edited /lib/pm-util/module.d/uswsusp to suspend using

strace s2ram --force --no_kms 1 --acpi_sleep 1 $OPTS &> /var/log/s2trace

I will get to the bottom of this...

Furthermore, an idea came: maybe we're looking into the wrong things? Maybe X is to blame? There was recently a big update...!

juchem

Member

Registered: 2012-07-30

Posts: 3

Re: [SOLVED]Linux3.4 broke resume/suspend some of the times in Lenovo T420

Have you looked at the thinkpad_acpi module? I'm new to this acpi stuff but doesn't it play a part in suspends / shutdowns? If my memory doesn't fail me, I had the issue even when I stopped GDM3 and logged in only through the console.

ayr0

Member

Registered: 2010-08-12

Posts: 94

Re: [SOLVED]Linux3.4 broke resume/suspend some of the times in Lenovo T420

Wow...a lot has happened since I last posted in this thread.

I'm back to report that I'm still experiencing this issue on my T520.  I have noticed that suspend seems to work more reliably when I select "Sleep" in KDE's menu.  I'm not sure what code is being executed when this happens.  Closing the lid on is successful about 7 times out of 10.

Are there any logs that would be helpful from my machine?

Essl

Member

Registered: 2012-07-15

Posts: 27

Re: [SOLVED]Linux3.4 broke resume/suspend some of the times in Lenovo T420

Is there an easy way that lets you figure out what command KDE invokes when you press the sleep button?

yourself

Member

Registered: 2008-10-23

Posts: 120

Re: [SOLVED]Linux3.4 broke resume/suspend some of the times in Lenovo T420

It shouldn't be something other than pm-suspend but the thing is that something else is happening when closing the lid that really messes things up....