[LENOVO 3249CTO] suspend/resume failure

[Steve Langasek]

The laptop frequently suspends/resumes successfully; it's been suspended/resumed probably at least a dozen times since the last reboot. I've seen intermittent suspend/resume failures before with previous kernel versions.

ProblemType: KernelOops
DistroRelease: Ubuntu 13.10
Package: linux-image-3.11.0-7-generic 3.11.0-7.14
ProcVersionSignature: Ubuntu 3.11.0-7.14-generic 3.11.1
Uname: Linux 3.11.0-7-generic x86_64
Annotation: This occured during a previous suspend and prevented it from resuming properly.
ApportVersion: 2.12.4-0ubuntu1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: vorlon 4171 F.... pulseaudio
 /dev/snd/pcmC0D0p: vorlon 4171 F...m pulseaudio
Date: Fri Sep 20 16:16:06 2013
ExecutablePath: /usr/share/apport/apportcheckresume
Failure: suspend/resume
HibernationDevice: RESUME=UUID=f6ab3c43-61b4-4af7-bf03-fa3b147a1de0
InstallationDate: Installed on 2010-09-24 (1092 days ago)
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
InterpreterPath: /usr/bin/python3.3
Lsusb:
 Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: LENOVO 3249CTO
MarkForUpload: True
ProcCmdline: /usr/bin/python3 /usr/share/apport/apportcheckresume
ProcEnviron:
 TERM=linux
 PATH=(custom, no user)
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.11.0-7-generic root=/dev/mapper/hostname-root ro quiet splash vt.handoff=7
PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: Daemon not responding.
RelatedPackageVersions:
 linux-restricted-modules-3.11.0-7-generic N/A
 linux-backports-modules-3.11.0-7-generic N/A
 linux-firmware 1.114
SourcePackage: linux
Title: [LENOVO 3249CTO] suspend/resume failure
UpgradeStatus: Upgraded to saucy on 2013-05-06 (137 days ago)
UserGroups:

WifiSyslog:

dmi.bios.date: 08/23/2010
dmi.bios.vendor: LENOVO
dmi.bios.version: 6QET52WW (1.22 )
dmi.board.name: 3249CTO
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr6QET52WW(1.22):bd08/23/2010:svnLENOVO:pn3249CTO:pvrThinkPadX201:rvnLENOVO:rn3249CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 3249CTO
dmi.product.version: ThinkPad X201
dmi.sys.vendor: LENOVO

[Brad Figg (brad-figg)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

So you don't see any suspend/resume failures anymore, but apport keeps prompting you to open bugs?

[Steve Langasek (vorlon)]

> So you don't see any suspend/resume failures anymore, but apport keeps
> prompting you to open bugs?

No, not at all. This *is* a suspend/resume failure.

[Joseph Salisbury (jsalisbury)]

Do you happen to recall the last 3.11 kernel that did not exhibit this bug?

Also, another helpful test would be to see if this happens with 3.12-rc2, which can be downloaded from:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12-rc2-saucy/

[Steve Langasek (vorlon)]

> Do you happen to recall the last 3.11 kernel that did not exhibit this bug?

I don't remember seeing this with 3.11.0-6, but that's not worth much; it may have just not become an issue for me that was worth reporting until I was traveling (and therefore suspending/resuming more often) and noticing a pattern.

FWIW, here's my history of kernel boots. It looks like I first booted 3.11.0-7 on September 13.

$ last -f /var/log/wtmp.1 | grep 'system boot'
reboot system boot 3.11.0-4-generic Sat Aug 31 12:15 - 09:56 (23+21:41)
reboot system boot 3.11.0-4-generic Wed Aug 28 13:37 - 09:56 (26+20:18)
reboot system boot 3.10.0-6-generic Thu Aug 22 12:33 - 09:56 (32+21:23)
reboot system boot 3.10.0-6-generic Sat Aug 10 09:53 - 12:31 (12+02:38)
$ last | grep 'system boot'reboot system boot 3.11.0-8-generic Tue Sep 24 09:23 - 09:58 (00:35)
reboot system boot 3.11.0-8-generic Mon Sep 23 18:49 - 09:58 (15:09)
reboot system boot 3.11.0-8-generic Sun Sep 22 13:48 - 09:58 (1+20:10)
reboot system boot 3.11.0-7-generic Fri Sep 20 15:25 - 09:58 (3+18:33)
reboot system boot 3.11.0-7-generic Fri Sep 20 14:16 - 09:58 (3+19:42)
reboot system boot 3.11.0-7-generic Tue Sep 17 20:11 - 09:58 (6+13:47)
reboot system boot 3.11.0-7-generic Sat Sep 14 13:53 - 09:58 (9+20:05)
reboot system boot 3.11.0-7-generic Fri Sep 13 19:33 - 13:52 (18:19)
reboot system boot 3.11.0-7-generic Fri Sep 13 11:34 - 19:32 (07:58)
reboot system boot 3.11.0-4-generic Fri Sep 13 11:30 - 11:30 (00:00)
reboot system boot 3.11.0-5-generic Fri Sep 13 11:30 - 11:30 (00:00)
reboot system boot 3.11.0-6-generic Fri Sep 13 11:29 - 11:29 (00:00)
reboot system boot 3.11.0-7-generic Fri Sep 13 11:28 - 11:28 (00:00)
reboot system boot 3.11.0-7-generic Fri Sep 13 11:27 - 11:27 (00:00)

[Steve Langasek (vorlon)]

So for the first time today I had occasion to try suspending my laptop when I wasn't in a hurry to immediately shove it in my bag, and observed the following:

 - on lid close, the "suspend" light blinks for a little while (as usual)
 - then the machine beeps (as usual)
 - the "suspend" light then goes solid (as usual) - but at this point, the fan is still running.
 - after about a minute, the machine powers off.

I've now rebooted to a 3.11.0-6 kernel, to see whether the problems persist.

[Steve Langasek (vorlon)]

This behavior (fans spinning on suspend, power off after a minute) is consistently reproducible at least back to 3.11.0-4. I definitely did not experience this problem while 3.11.0-4 was current. So it looks like something else may have changed to cause this bug.

I am able to reproduce the failure even by running pm-suspend manually from the console (VT1). I normally run thinkfan, but I've disabled it in the startup and changed the module options to disallow fan control; none of these changes make any difference, the failure is consistently reproducible (at this point, approximately 100% of the time).

[Colin Ian King (colin-king)]

Steve, just to factor out some of the pm-utils complexity can you boot into 3.11.0-4 and switch to a console and try:

echo mem | sudo tee /sys/power/state

and see if that works.

Failing that, do you have any earlier kernels to try this out on to see if they work or fail?

[Steve Langasek (vorlon)]

On Thu, Oct 10, 2013 at 09:32:24AM -0000, Colin King wrote:
> Steve, just to factor out some of the pm-utils complexity can you boot
> into 3.11.0-4 and switch to a console and try:

> echo mem | sudo tee /sys/power/state

> and see if that works.

That's a great question. Last night, my results were:

 - booted into 3.11.0-4
  - switched to VT1
   - laptop plugged into the dock (so, on A/C power)
    - echo mem > /sys/power/state
     - worked, resumed successfully.
    - ran pm-suspend
     - worked, resumed successfully.
   - unplugged the laptop from the dock
    - ran pm-suspend again
     - failed
 - booted into 3.11.0-12
  - kept the laptop unplugged from the dock
   - switched to VT1
    - echo mem > /sys/power/state
     - resumed successfully
    - pm-suspend
     - resumed successfully
   - switched to X
    - pm-suspend
     - failed

So I took some time today to test a bit more systematically, and take notes
as I went. The notes are below, but the summary is: whatever has changed to
make suspend unreliable on my laptop, it appears *not* to be the OS. I've
rolled back the kernel, and I've even rolled back userspace, to raring, and
the problem is still reproducible.

I wonder whether Ubuntu didn't do something to trigger this behavior change,
but if it did, it's now persistent somewhere in nvram.

So if nobody else is reporting similar problems, I guess this is specific to
my hardware and not a kernel bug.

3.11.0-12: docked, X, pm-suspend: fail
 - power on -
3.11.0-4: docked, console, echo mem: fail
 - power on -
3.11.0-4: docked, console, echo mem: success
3.11.0-4: docked, console, echo mem: success
3.11.0-4: docked, console, echo mem: success
3.11.0-4: docked, console, echo mem: success
3.11.0-4: docked, console, echo mem: success
3.11.0-4: docked, console, echo mem: success
3.11.0-4: docked, console, pm-suspend: success
3.11.0-4: docked, console, pm-suspend: success
3.11.0-4: docked, console, pm-suspend: success
3.11.0-4: docked, console, pm-suspend: success
3.11.0-4: docked, console, pm-suspend: success
3.11.0-4: docked, X, pm-suspend: fail
 - power on -
3.11.0-4: docked, console, echo mem: fail
 - power on -
3.11.0-4: docked, console, echo mem: fail
 - power on -
3.11.0-4: docked, console, echo mem: fail
 - power on; takes a long time to POST; does not reach the bootloader -
 - power off -
 - power on -
3.11.0-4: docked, console, echo mem: success
3.11.0-4: docked, console, pm-suspend: success
3.11.0-4: docked, console, pm-suspend: success
3.11.0-4: docked, console, pm-suspend: fail
 - power on -
3.11.0-4: docked, console, pm-suspend: fail
 - power on -
3.11.0-4: docked, console, pm-suspend: fail
 - power on -
3.11.0-4: docked, console, pm-suspend: fail
 - power on -
3.11.0-4: docked, console, echo mem: fail
 - power on -
3.11.0-4: docked, console, echo mem: fail
 - power on -
3.11.0-4: docked, console, echo mem: fail
 - power on -
3.8.0-19: docked, console, echo mem: success
3.8.0-19: docked, console, echo mem: fail
 - power on -
3.8.0-19: docked, console, echo mem: success
3.8.0-19: docked, console, echo mem: success
3.8.0-19: docked, console, echo mem: success, but video did not come back up after resume
 - power off -...

[Colin Ian King (colin-king)]

Does kernel parameter "acpi_sleep=sci_force_enable" help in any way?

[Colin Ian King (colin-king)]

Ignore that comment, this bit is already forced on suspend nowadays.

[Colin Ian King (colin-king)]

One thing to try is to reset to factory defaults on the firmware and boot (to see if it still works!). Then shutdown, remove AC and battery and wait 5 or so minutes to ensure everything like the Embedded Controller is completely off and then plug in the battery and AC and see if suspend/resume is any more reliable.

[Furkan (falaca)]

I've had this issue ever since I first put Ubuntu (13.04) on my laptop in May. I updated my kernel to 3.11.1-031101-generic 2-3 weeks ago and it hasn't happened since. I don't know if it's just luck, or if it's actually been fixed (there have been other times where it hadn't happened in a while, but usually it happens at least once every few days).

[Furkan (falaca)]

I should add that I have the same laptop as Steve (Thinkpad X201).

[Colin Ian King (colin-king)]

@Steve, perhaps you can confirm if 3.11.1-031101 solves the problem. If so, I can start to track down any potential fixes we're missing.

packages in: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.11.3-saucy/

[Steve Langasek (vorlon)]

On Mon, Oct 14, 2013 at 10:09:17AM -0000, Colin King wrote:
> One thing to try is to reset to factory defaults on the firmware and
> boot (to see if it still works!). Then shutdown, remove AC and battery
> and wait 5 or so minutes to ensure everything like the Embedded
> Controller is completely off and then plug in the battery and AC and see
> if suspend/resume is any more reliable.

On Tue, Oct 15, 2013 at 01:15:08PM -0000, Colin King wrote:
> @Steve, perhaps you can confirm if 3.11.1-031101 solves the problem. If
> so, I can start to track down any potential fixes we're missing.

> packages in: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.11.3-saucy/

Sad to say that neither the new kernel nor resetting the BIOS to factory
defaults did the job.

[penalvch (penalvch)]

Steve Langasek, as per http://download.lenovo.com/express/ddfm.html an update is available for your BIOS (6QET70WW). If you update to this following https://help.ubuntu.com/community/BiosUpdate , does it change anything?

If not, could you please both specify what happened, and provide the output of the following terminal command:
sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date

Thank you for your understanding.

[Steve Langasek (vorlon)]

No. I have an aftermarket wlan card in this system that prevents using the stock bios from Lenovo, and Tue tools for unpacking bios images for modification appear to have bit rotted.

[Furkan (falaca)]

It's been another 10 days since I last posted, and I still haven't encountered this bug again. I have no idea if it was the new kernel version or the BIOS that "fixed" it - I updated them both within a couple of days of eachother, so I am running the latest BIOS that Christopher linked to. Of course it could also be that I'm on a lucky streak, since I've never been able to consistently replicate the bug - but before I updated the BIOS + kernel it was happening on approximately a weekly basis.

I sort of doubt that the BIOS would be the issue though (but you never know), since I've had this laptop since April 2010 and I've never faced the issue while running Windows 7 (I just switched over to Ubuntu in May).

Steve, I tried to replicate your results by running echo mem > /sys/power/state and pm-suspend on AC power while docked, and then pm-suspend again while undocked, and it seems to work fine. Do you have any further detailed suggestions on how I could try to replicate the issue?

[Steve Langasek (vorlon)]

On Sun, Oct 27, 2013 at 01:25:26AM -0000, Furkan Alaca wrote:
> It's been another 10 days since I last posted, and I still haven't
> encountered this bug again. I have no idea if it was the new kernel
> version or the BIOS that "fixed" it - I updated them both within a
> couple of days of eachother, so I am running the latest BIOS that
> Christopher linked to. Of course it could also be that I'm on a lucky
> streak, since I've never been able to consistently replicate the bug -
> but before I updated the BIOS + kernel it was happening on approximately
> a weekly basis.

> I sort of doubt that the BIOS would be the issue though (but you never
> know), since I've had this laptop since April 2010 and I've never faced
> the issue while running Windows 7 (I just switched over to Ubuntu in
> May).

Well, I've had this one since October 2010, always running Ubuntu, and it
didn't start having problems until September.

Maybe there's code in the BIOS that starts misbehaving only after a certain
date. I could try setting the clock back to test.

> Steve, I tried to replicate your results by running echo mem >
> /sys/power/state and pm-suspend on AC power while docked, and then pm-
> suspend again while undocked, and it seems to work fine. Do you have any
> further detailed suggestions on how I could try to replicate the issue?

No, if the problem isn't reproducible for you that way, then you seem to be
unaffected. It's quite possible that the problem is caused by a hardware
failure on my machine.

[Colin Ian King (colin-king)]

I wonder if the issue is because you have a different wireless card and this is causing the firmware some issues when coming up from a clean start on resume.

[Steve Langasek (vorlon)]

On Mon, Oct 28, 2013 at 07:21:51PM -0000, Colin King wrote:
> I wonder if the issue is because you have a different wireless card and
> this is causing the firmware some issues when coming up from a clean
> start on resume.

It's not a matter of anything happening on resume, fwiw; it doesn't suspend
correctly. On suspend, the kernel has handed off, the 'good night, moon'
light turns on, but the fan is still running and then after a minute
something notices and shuts the whole system down.

[Colin Ian King (colin-king)]

I've added a considerable amount of debug into the suspend path in the kernel.

1. Edit /etc/default/grub and set:

GRUB_CMDLINE_LINUX_DEFAULT="loglevel=7 no_console_suspend"

2. Download and install the kernel .debs from:

http://kernel.ubuntu.com/~cking/lp-1228406/v1/

3. Reboot
4. Switch to console #1
5. login
6. run:

sudo pm-suspend

Note down the last kernel messages you see. If the screen blanks and the machine turns off before you see any messages, I will add some delays to printk() when suspend in invoked and re-spin a new kernel.

Colin

[Colin Ian King (colin-king)]

@Steve, as per discussion on IRC, you mentioned that this bug may be due to just buggy H/W. Do you want to keep this bug open?

[Steve Langasek (vorlon)]

So, here's something funny. The suspend/resume failures started happening for me on September 20, almost exactly 3 years after I'd gotten the machine; and was reproducible with older kernels and OSes that had previously worked fine. I had joked that maybe the BIOS had a time bomb in it, or just knew its time was up because I was due for a laptop refresh, and decided to try setting the BIOS clock back to before September 20th to see if it made any difference.

I set the BIOS clock back exactly 3 months, to September 2. I have now had 8 successful suspend/resumes in a row with no problems. After the third suspend/resume, I set the clock back to the current date and the problem has still not recurred.

I have no idea why this actually made a difference, of course; but it seems to have done so.

I guess this bug should be closed as invalid, unless you're interested in having me poke this BIOS harder, Colin.

[Steve Langasek (vorlon)]

I did just have a suspend/resume failure, but it was the first one after many repeated test suspend/resume cycles and it was also the first time I was transporting the laptop so could have been a physical connection coming loose anyway (I thought it had suspended successfully before I put it in the bag).

The other thing I notice is that, judging by the fans while the laptop is in use, the system is now also much less loaded than it was when it was having the suspend/resume problem. Given that the symptom was the fans not shutting off when suspending, followed by a power off, perhaps this says something about the root cause.