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

yourself · 2012-07-18 07:04:22

What I've noticed is this.

Suppose that things go wrong in a suspend procedure and I resume the laptop to find it has dropped to the display manager. I log in to the console (Ctrl+Alt+F1) and issue a 'reboot' command. What happens is that exactly after I see the "Sending SIGTERM to processes" message, my laptop suspends. It is as if some running process is blocking the suspend, but the suspend command is still pending (and completes after the blocking process is killed)! Furthermore, after I resume it (and it completes the reboot) I always see messages like this on the console:

[ 5911.415413] BUG: Bad rss-counter state mm:ffff880116bea300 idx:1 val:-1
[ 5911.415417] BUG: Bad rss-counter state mm:ffff880116bea300 idx:2 val:1

I'll try killing one by one all the processes next time and see what happens...

Furthermore, I've downgraded to linux-3.3.8...

Will report back my findings...

Last edited by yourself (2012-07-18 07:05:24)

yourself · 2012-07-18 08:32:38

Oh, linux-3.4.5 came out just now, featuring (as they say in the internet) the fix to this BUG: Bad rss-counter state .... stuff, so let's see how this goes! Maybe the suspend problems are fixed, too!

thesequel · 2012-07-19 06:10:03

Did the new kernel fix this issue?

yourself · 2012-07-19 08:44:54

No, it did not. The behavior is exactly the same.

Some more info... This morning, it happened again. I have noticed it that it happens about after about 24 hours from reboot, with suspend/resume cycles in between.

I now have my system at login prompt after a failed suspend. I ran init 3 to do away with X and its bloat and here we are:

dmesg says in its last 2 lines:

[19554.091407] PM: Syncing filesystems ... done.
[19554.093717] PM: Preparing system from mem sleep

And this is it. No more messages, no more anything.

ps ax shows, among others:

23375 ?      S      0:00 /bin/sh /usr/sbin/pm-suspend
23521 ?      S     0:00 s2ram --force

both of them sleeping, waiting for something that never happens?

Furthermore, echo "mem" > /sys/power/state fails:

echo "mem" > /sys/power/state
-bash: echo: write error: Device or resource busy

Last, /var/log/pm-suspend has the following:

enabled, active

/usr/lib/pm-utils/sleep.d/01laptop-mode resume suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/01grub resume suspend:

/usr/lib/pm-utils/sleep.d/01grub resume suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/00powersave resume suspend:

/usr/lib/pm-utils/sleep.d/00powersave resume suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/00logging resume suspend:

/usr/lib/pm-utils/sleep.d/00logging resume suspend: success.
Thu Jul 19 09:19:01 EEST 2012: Finished.
Initial commandline parameters: 
Thu Jul 19 10:19:58 EEST 2012: Running hooks for suspend.
Running hook /usr/lib/pm-utils/sleep.d/00logging suspend suspend:
Linux thinky 3.4.5-1-ARCH #1 SMP PREEMPT Mon Jul 16 21:35:54 CEST 2012 x86_64 GNU/Linux
Module                  Size  Used by
iwlwifi               311114  0 
vboxdrv              1792406  0 
mei                    32152  0 
rtl8187                52559  0 
eeprom_93cx6            2175  1 rtl8187
mac80211              395712  2 iwlwifi,rtl8187
cfg80211              170074  3 iwlwifi,mac80211,rtl8187
fuse                   68768  4 
xt_hl                   1369  6 
ip6t_rt                 2112  3 
nf_conntrack_ipv6       6650  6 
nf_defrag_ipv6          6401  1 nf_conntrack_ipv6
ipt_REJECT              2281  1 
xt_limit                2041  1 
xt_tcpudp               2471  20 
xt_addrtype             2853  4 
xt_state                1295  12 
ip6table_filter         1396  1 
ip6_tables             18198  2 ip6table_filter,ip6t_rt
nf_conntrack_netbios_ns     1077  0 
nf_conntrack_broadcast     1285  1 nf_conntrack_netbios_ns
nf_nat_ftp              1668  0 
nf_nat                 15100  1 nf_nat_ftp
nf_conntrack_ipv4       6871  8 nf_nat
nf_defrag_ipv4          1339  1 nf_conntrack_ipv4
nf_conntrack_ftp        6261  1 nf_nat_ftp
nf_conntrack           61584  8 nf_nat_ftp,nf_conntrack_netbios_ns,nf_nat,xt_state,nf_conntrack_broadcast,nf_conntrack_ftp,nf_conntrack_ipv4,nf_conntrack_ipv6
iptable_filter          1456  1 
ip_tables              16946  1 iptable_filter
x_tables               16954  11 ip6table_filter,xt_hl,ip_tables,xt_tcpudp,xt_limit,xt_state,iptable_filter,ip6t_rt,ipt_REJECT,ip6_tables,xt_addrtype
joydev                  9991  0 
snd_hda_codec_hdmi     23672  1 
snd_hda_codec_conexant    46154  1 
uvcvideo               69437  0 
videobuf2_vmalloc       2468  1 uvcvideo
videobuf2_memops        2246  1 videobuf2_vmalloc
videobuf2_core         20415  1 uvcvideo
videodev               93086  1 uvcvideo
arc4                    1410  2 
media                  10213  2 uvcvideo,videodev
aesni_intel            43154  0 
aes_x86_64              7508  1 aesni_intel
aes_generic            26138  2 aesni_intel,aes_x86_64
ghash_clmulni_intel     4237  0 
cryptd                  8741  2 ghash_clmulni_intel,aesni_intel
sdhci_pci              10833  0 
sdhci                  23854  1 sdhci_pci
snd_hda_intel          24053  5 
coretemp                5654  0 
serio_raw               4653  0 
snd_hda_codec          94305  3 snd_hda_codec_hdmi,snd_hda_codec_conexant,snd_hda_intel
mmc_core               82070  2 sdhci,sdhci_pci
snd_hwdep               6300  1 snd_hda_codec
psmouse                70792  0 
snd_pcm                74958  3 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel
crc32c_intel            1987  0 
snd_page_alloc          7217  2 snd_pcm,snd_hda_intel
i2c_i801                8180  0 
snd_timer              18966  1 snd_pcm
iTCO_wdt               12813  0 
iTCO_vendor_support     1929  1 iTCO_wdt
thinkpad_acpi          62497  1 
e1000e                146474  0 
nvram                   5906  1 thinkpad_acpi
microcode              12185  0 
rfkill                 15604  2 cfg80211,thinkpad_acpi
snd                    58997  20 snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_hda_codec_conexant,snd_pcm,snd_hda_codec,snd_hda_intel,thinkpad_acpi
thermal                 7959  0 
soundcore               5410  1 snd
battery                 6517  0 
ac                      2376  0 
evdev                   9754  22 
cpufreq_powersave        990  0 
acpi_cpufreq            5933  1 
mperf                   1267  1 acpi_cpufreq
processor              26567  1 acpi_cpufreq
nfs                   276056  0 
nfs_acl                 2359  1 nfs
lockd                  62987  1 nfs
auth_rpcgss            32327  1 nfs
sunrpc                184998  4 nfs,auth_rpcgss,lockd,nfs_acl
fscache                41059  1 nfs
ext4                  424175  1 
crc16                   1359  1 ext4
jbd2                   73919  1 ext4
mbcache                 5977  1 ext4
sd_mod                 29239  3 
ahci                   20549  2 
libahci                20023  1 ahci
ehci_hcd               41026  0 
libata                167611  2 ahci,libahci
usbcore               147565  4 uvcvideo,rtl8187,ehci_hcd
scsi_mod              132974  2 libata,sd_mod
usb_common               954  1 usbcore
i915                  438144  3 
video                  11307  1 i915
button                  4502  1 i915
i2c_algo_bit            5391  1 i915
intel_agp              10936  1 i915
intel_gtt              14047  3 i915,intel_agp
drm_kms_helper         33051  1 i915
drm                   208958  4 i915,drm_kms_helper
i2c_core               20369  6 drm,i915,i2c_i801,drm_kms_helper,i2c_algo_bit,videodev
             total       used       free     shared    buffers     cached
Mem:       3933956    1331008    2602948          0     245252     678776
-/+ buffers/cache:     406980    3526976
Swap:      9802196     163536    9638660

/usr/lib/pm-utils/sleep.d/00logging suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/00powersave suspend suspend:

/usr/lib/pm-utils/sleep.d/00powersave suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/01grub suspend suspend:

/usr/lib/pm-utils/sleep.d/01grub suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/01laptop-mode suspend suspend:

/usr/lib/pm-utils/sleep.d/01laptop-mode suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/49bluetooth suspend suspend:

/usr/lib/pm-utils/sleep.d/49bluetooth suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/75modules suspend suspend:
Unloading kernel module iwlwifi...Done.

/usr/lib/pm-utils/sleep.d/75modules suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/90clock suspend suspend:

/usr/lib/pm-utils/sleep.d/90clock suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/94cpufreq suspend suspend:

/usr/lib/pm-utils/sleep.d/94cpufreq suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/95led suspend suspend:

/usr/lib/pm-utils/sleep.d/95led suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/98video-quirk-db-handler suspend suspend:
Kernel modesetting video driver detected, not using quirks.

/usr/lib/pm-utils/sleep.d/98video-quirk-db-handler suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/99video suspend suspend:

/usr/lib/pm-utils/sleep.d/99video suspend suspend: success.
Thu Jul 19 10:19:58 EEST 2012: performing suspend

Essl · 2012-07-19 11:56:25

24 hours after reboot you say? I don't think that's true for me, it's usually more I would guess. I'll time myself next time this occurs I suppose.

Maybe it has something to do with memory usage.

yourself · 2012-07-19 12:04:00

Yes, it is approximately after 24 hours (but it definitely is not the number of suspend/resume cycles because the other day I just sat there doing suspend/resume cycles which went ok)

I have downgraded my kernel to 3.3.8 (along with the corresponding virtualbox which is now 4.1.14 instead of 4.1.18) for now and will check if this fixes the situation....

Essl · 2012-07-19 20:35:12

I tried the same thing with suspend cycles/resume, had the same result. I can't imagine why it might be time, but I figure something like memory usage might go up as you open more programs/tabs and time passes, which is why I think that may be a cause.

Essl · 2012-07-20 11:35:40

I had the thing happen to me yesterday. I couldn't change the terminal, because the terminals would just show "ACPI: Unable to dock", but I was able to log into a dwm session from where i opened an xterm to reboot, and indeed it started rebooting, went into sleep mode and then after being woken up, finished rebooting.

yourself · 2012-07-21 11:42:48

This is definitely a bug somewhere but I cannot pinpoint the source of the problem, even in terms of package. Is it the kernel, is it acpi, is it something else?
I have enabled PM_DEBUG and will diff /var/log/pm-suspend.log when the failure occurs with a normal one, maybe this will give us some clue...

Last edited by yourself (2012-07-21 11:44:07)

yourself · 2012-07-22 00:07:05

Now this is very weird. I have enabled PM_DEBUG and this is what /var/log/pm-suspend.log has in the event of a proper suspend/resume cycle: https://dl.dropbox.com/u/63420/suspend.log.ok
And this is in the event of a failed one: https://dl.dropbox.com/u/63420/suspend.log.notok

There are a couple of interesting points to notice
1. One glaring difference is that they differ only in the initial active/not active (which I believe is referring to laptop_mode_tools)
2. They are the same up to line 381 (when the OK version ends). What goes beyond that in the not ok is beyond my comprehension....

Seems that laptop_mode_tools might have something to do here, but I disabled it the other time with no success... Maybe I'll try completely removing it (along with the new kernel 3.4.6, this might get me somewhere)...

Any other ideas based on these two files?

Essl · 2012-07-22 13:06:49

i did pacman -R laptop-mode-tools after I found this thread and am still having this problem, so I doubt it. (i removed it from my rc.conf as well)

yourself · 2012-07-22 15:39:09

I posted the files on the pm-utils mailing list, see if I get anything interesting from them...

Last edited by yourself (2012-07-22 16:02:32)

yourself · 2012-07-24 12:08:35

Nothing yet from pm-utils mailing list but this has happened with 3.4.6, with 1d 19mins of uptime.

This time I went looking for trouble and run sudo pm-suspend from command line. The problem manifested itself a bit differently as there was no sleep led flashing (which led be to believe that everything went fine) but when I resumed, my desktop had dropped again back to the login manager and when I typed 'init 3' to completely 'kill' the display manager (don't ask, I don't know why I did that), the console in Ctrl+alt+F7 was filled with info about a glibc detected free(): invalid pointer originating within /usr/bin/X (I couldn't completely decypher it because the text was kind of garbled with no proper line feeds).

Anyway it's driving me insane!!!

Maybe 3.5.0 fixed it? I've installed it and keep you posted....

yourself · 2012-07-25 06:16:11

No, 3.5 did not fix this issue...
Back to square 1.

I'm running low on ideas. Anyone?

dschrute · 2012-07-25 09:49:58

I'm having the same issue on a E420. Sorry, no ideas on how to fix or where to look.

On my machine it happens every 4th to 5th time I suspend ( or hibernate for that matter ) regardless of the length of time since it last happened.
One thing I did notice though is that it only happens when the suspend/hibernate is initiated by closing the lid or system inactivity timeout. I'm using XFCE as my DE and I have never had the issue if, using the XFCE menu, I choose "Log out -> Suspend/Hibernate" or if I use the XFCE Power Manager tray app and choose Suspend or Hibernate from there. Those always work ?!

I've got the Power Manager configured so that on battery closing the lid hibernates and to sleep after 15 minutes, while on AC closing the lid suspends and to sleep after 30 minutes. This works, but as I said every 4-5 times the suspend gets "hung" and when I go back in, log in and restart the suspend "finishes" after the reboot.

I don't know what the difference is with using the XFCE menu or tray app to initiate a suspend, but they just never cause the problem.

yourself · 2012-07-25 10:47:08

Hey dschrute!

Mine is not manifested every 4th or 5th time (I've sat on time opening and closing the lid for at least 30 times - nothing happened) but definitely after some time from boot (could be 13-14 hours or 24+, but I never reach 48 hours, i.e 2 days straight with suspend/resume cycles). Granted, it happens after about 6-7 cycles but these are the average number of suspend/resumes I do in about 13 to 30 hours. Have you tried sitting there and doing suspend/resume cycles? I forecast that nothing will happen to you, as well.

I'm using XFCE, too, but don't really think that it is responsible for it since I have been using it a couple of years now and had no such problems in the past. It's very interesting that you say it works if you suspend by not closing the lid, but as for me, I've had it happen once after issuing sudo pm-suspend. So for me, I guess, the problem is rooted elsewhere. Are you absolutely certain that these options always work?

More interestingly, this happens *regardless* if I'm using uswsusp or kernel suspend. Something fishy is going on here....

For now, I've downgraded (once again) to 3.3.8 and see if I can reach 3 days without this thing happening. If it does not, the kernel might have something to do with it...

dschrute · 2012-07-25 14:12:04

Are you absolutely certain that these options always work?

I guess I can't say they always work, only that so far the problem has never occurred when hibernating/suspending using the menus :-\
It's been 3+ days, and at least a couple dozen instances since it happened, but I've only been using the menus in that time and when it last happened I know I closed the lid. Normally it would have happened at lest twice in that amount of time had I not been consciously avoiding closing the lid. I also haven't manually run sudo pm-suspend, so I can't comment on that.

I'm using XFCE, too, but don't really think that it is responsible for it since I have been using it a couple of years now and had no such problems in the past.

I wouldn't say I think XFCE is responsible for the issue, especially since you've had the problem when manually running pm-suspend. I just think it's very odd that using the XFCE menus has never resulted ( for me anyway ) in the problem occuring. I wonder what, if anything, is done differently when suspend is invoked that way as opposed to closing the lid.
Since you're using XFCE, maybe you could try using only the menus for a day or so + see what happens on your side.

I haven't really had the time ( or patience ) to repeatedly test different scenarios, plus I think if my 2 year old sees me opening/closing the laptop over and over he'll think it's a game and want to join in.
But it's getting to the point that I'm annoyed enough with the issue that I think I'm going to have to give it a try. When I do I'll post here again with results.

Last edited by dschrute (2012-07-25 14:19:16)

yourself · 2012-07-25 15:06:59

I'm currently evaluating my suspend/resume mileage under linux-3.3.8 but after that, I'll revert back to 3.4.6/3.5.0 (whatever is in core then) and try suspending from the logout options and see what happens...

yourself · 2012-07-25 19:02:09

Bummer!! 3.3.8 also did it!! Will try 3.4.6 using XFCE's buttons. (Wouldn't it be extremely weird??)

Last edited by yourself (2012-07-25 19:05:06)

Dusty · 2012-07-26 15:33:08

How often do you guys run pacman -Syu?

I'm experiencing the same intermittent problem with a T510. My theory (as unfounded as any other) is that when I run pacman -Syu, certain packages sync in that are interfering with suspend until a reboot. I originally thought it was kernel modules, which is pretty obvious, but the kernel hasn't updated in a while and it's still happening.

It could be gremlins.

Dusty

yourself · 2012-07-26 19:08:38

Well, I run

$ yaourt -Sy && yaourt -Sua

on a daily basis. I would be EXTREMELY surprized if this was the cause since (in theory) all this does (if there are no packages to update) update the local package databases
( /var/lib/pacman/sync/{repo}.db ). On the other hand, we all know that things are not always what they seem, so if this is your feeling, then this is what I'll try next, if suspending by the logout command buttons of XFCE fails.... Of course, if packages *do* get updated, that's another story altogether but still, in theory, it *shouldn't* have any effect!!

And, I've been running it for years with no problems...!

Although I'm starting to lean on the theory that gremlings exist and tamper with our laptops!!!!

(Damn thing, it's making us really superstitious!!)

Last edited by yourself (2012-07-26 19:24:41)

Essl · 2012-07-26 22:40:54

Dusty wrote:

How often do you guys run pacman -Syu?
I'm experiencing the same intermittent problem with a T510. My theory (as unfounded as any other) is that when I run pacman -Syu, certain packages sync in that are interfering with suspend until a reboot. I originally thought it was kernel modules, which is pretty obvious, but the kernel hasn't updated in a while and it's still happening.
It could be gremlins.
Dusty

definitely not. This has happened to me when I hadn't updated at all. I suspected the same thing as you, but turned out to be wrong. (then again, I do seem to have this happen to me a lot less than most people in this thread. I can go fairly long (as in longer than a week) without it happening, using the laptop heavily every day -- i always have it on the cable and it doesn't suspend from inactivity)

Last edited by Essl (2012-07-26 22:43:10)

yourself · 2012-07-28 09:52:41

Well, guys, I'm already on 60+ hours with normal suspend/resume cycles (but suspending only from the XFCE buttons) and everything is running smoothly. This leads me to believe that since the problem manifests itself only when closing the lid, the ACPI subsystem is messing things up.

(One other difference is that I now have SUSPEND_MODULES="iwlwifi uhci_hcd button" in my /etc/pm/config.d/modules)

Maybe we should start looking into ACPI?

dschrute · 2012-07-28 13:03:50

Do you have acpid running ? In looking at the acpid wiki page there's a big, fat warning about desktop environments and their handling of acpi events conflicting wit acpid. Of course I didn't see it before ( Doh! ) but it warns about conflicts between acpid and a DE trying to handle the same event.

I did have acpid running, and just disabled it to test. It's been so long since I set this up that I don't remember the sequence, but I think at the time I assumed acpid needed to be running regardless of what other power management tools I was using. Disabling it completely probably isn't the best way to go, since if I'm not in XFCE I'll probably lose some functionality, but for now it should be easy to test and if it works out I can always re-enable and tweak specific events to avoid conflicts.

Anyway, it kind of makes sense since a physical event like closing the lid or pressing the button would definitely trigger something in acpid, but using an XFCE menu item would probably be ignored by acpid and pass directly to whatever XFCE is using.
So we'll see. Maybe not a bug after all, but just a misconfiguration that older kernels were more forgiving of.

goran'agar · 2012-07-28 13:45:56

yourself wrote:

Well, guys, I'm already on 60+ hours with normal suspend/resume cycles (but suspending only from the XFCE buttons) and everything is running smoothly. This leads me to believe that since the problem manifests itself only when closing the lid, the ACPI subsystem is messing things up.
(One other difference is that I now have SUSPEND_MODULES="iwlwifi uhci_hcd button" in my /etc/pm/config.d/modules)
Maybe we should start looking into ACPI?

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.

Arch Linux

#26 2012-07-18 07:04:22

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

#27 2012-07-18 08:32:38

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

#28 2012-07-19 06:10:03

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

#29 2012-07-19 08:44:54

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

#30 2012-07-19 11:56:25

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

#31 2012-07-19 12:04:00

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

#32 2012-07-19 20:35:12

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

#33 2012-07-20 11:35:40

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

#34 2012-07-21 11:42:48

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

#35 2012-07-22 00:07:05

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

#36 2012-07-22 13:06:49

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

#37 2012-07-22 15:39:09

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

#38 2012-07-24 12:08:35

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

#39 2012-07-25 06:16:11

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

#40 2012-07-25 09:49:58

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

#41 2012-07-25 10:47:08

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

#42 2012-07-25 14:12:04

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

#43 2012-07-25 15:06:59

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

#44 2012-07-25 19:02:09

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

#45 2012-07-26 15:33:08

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

#46 2012-07-26 19:08:38

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

#47 2012-07-26 22:40:54

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

#48 2012-07-28 09:52:41

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

#49 2012-07-28 13:03:50

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

#50 2012-07-28 13:45:56

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

Board footer