Maverick won't resume (lucid will) on Lenovo S10-3

I have the same issue with some new information:

* I can suspend (amd resume!) just fine when i've booted off the netbook remix live image
* Can't resume when booted off the installed version. I've patched it up with latest updates. Have kernel 2.6.35-22-generic installed (same package as OP).

I don't exactly understand what is going on however i'm willing to gather more info / test any fixes. Machine is currently a mostly vanilla install, and i'm happy enough to bring it back to a vanilla install to test if need be.

I just tried the latest kernel mainline from
http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/

Resume still fails the same way.

I booted 2.6.35-23-generic with i915.modeset=0 on the kernel command-line, just to take kernel modesetting out of the equation. The kernel booted to a text console. I then did

            echo mem > /sys/power/state

The system appears to have suspended normally. But, it freezes upon waking up, just as Serge described.

I then tried a mainline 2.6.35.9 kernel with this .config: http://sr71.net/~dave/linux/config-s10-3-2.6.35.9 . *THAT* kernel resumes after "echo mem > /sys/power/state" just fine. So, apparently there's something in the Maverick 2.6.35 kernel which breaks things which is completely specific to Maverick.

Ubuntu 2.6.34 kernel with stock config resumes fine. Starting a very slow
bisect (it says 14 steps)

I _think_ this may be more complicated than we first thought. I've now seen cases where the Ubuntu 2.6.35-23-generic kernel suspends and resumes fine. I've also seen cases where recent mainline (2.6.37-rc7) doesn't resume properly. They seem to do this in bunches. I couldn't get it to suspend at all for most of the last week and this morning it started miraculously working again.

Somehow, I haven't been saving the early boot dmesg logs. I'll start saving those and see if I can make any conclusions about what changes in the configurations.

But, I'm becoming less and less sure that this is an Ubuntu-specific kernel bug.

After reading some arch linux sites, I tried again booting a natty kernel with intel_idle.max_cstate=0. With that, I can resume after suspend about half the time. On the lucid kernel, it fails the same way about one every 10 or 20 suspends at most - but does sometimes fail.

Dave, have you learned any more?

I haven't. It's still stumping me. I will try the cstate thing for a
bit and see how it turns out.

Quoting DaveHansen (<email address hidden>):
> I haven't. It's still stumping me. I will try the cstate thing for a
> bit and see how it turns out.

I'm thinking it may pay off for me to dump some info on the usb devices
before shutdown. I think the intel idle made it always break, and
acpi_idle does a better job. So I think the failures I get now are
different.

I wonder if anyone understands why we need to hit the power button after
opening the lid in order to make suspend proceed. Finding and fixing
that may be the key here.

> I wonder if anyone understands why we need to hit the power button after
> opening the lid in order to make suspend proceed. Finding and fixing
> that may be the key here.

Hah! I thought the power button trick was my little secret.

I've not had as much success with the power button when I close and open
the lid to suspend. It seems much happier if I do it from software (hit
power, then click the suspend button in the popup). No idea why...

-- Dave

Quoting DaveHansen (<email address hidden>):
> > I wonder if anyone understands why we need to hit the power button after
> > opening the lid in order to make suspend proceed. Finding and fixing
> > that may be the key here.
>
> Hah! I thought the power button trick was my little secret.
>
> I've not had as much success with the power button when I close and open
> the lid to suspend. It seems much happier if I do it from software (hit
> power, then click the suspend button in the popup). No idea why...

Hm. Yes, so far my three attempts at suspending from the menu have
successfully been restored! Shutting the lid seems to always or
almost always fail.

With intel_idle disabled, suspend/resume was reliable in Maverick. Just upgraded to Natty and resume fails with and without intel_idle. Lenovo S10-3

Quoting Benn (<email address hidden>):
> With intel_idle disabled, suspend/resume was reliable in Maverick. Just
> upgraded to Natty and resume fails with and without intel_idle. Lenovo
> S10-3

With natty and intel_idle disabled, suspend from the top right menu was
almost always resulting in correct resumes for me until a few weeks ago.
Suddenly it got back to failing every time. (S10-3) Sorry I'm not
sure exactly which kernel broke it again.

In the hopes of one day finding out the diff between working and non-working:

Linux peqn 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:50 UTC 2011 i686 i686 i386 GNU/Linux

is resuming fine (at least when suspended from the pull-down menu).

One little note from Debian:http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635575#42
> Debian kernels do not include the intel_idle driver.

Whatever is going on, it's fairly widespread, and other people seem to see it:
http://marc.info/?l=linux-kernel&m=131459136817352&w=2
Although, I do question if the bisect really found the cause, or this is just something spurious caused the bisect to point here.

We also know that the chipset is quirky:
http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4731fdcf6f7bdab3e369a3f844d4ea4d4017284d

With CONFIG_INTEL_IDLE=y *AND* intel_idle.max_cstate=0, the system consistently suspend/resumes 2.6.39.4.
With CONFIG_INTEL_IDLE=n, the system consistently suspend/resumes with 2.6.39.4.

IOW, intel_idle triggers the problem, except when disabled at compile or runtime. acpi_idle seems OK. I bet Windows uses ACPI and that's why nobody sees this on Windows.

Note: this is suspend/resume with Fn-F4, the lid, or from software. I can't get the "pull-down, then fiddle with the power button to resume" hack to work any more.

It is still a problem with Ubuntu 11.10 beta 1

Update: in the past, suspend/resume appeared mainly to be broken with the intel idle driver. However since some time after 3.1, it is broken even without the intel idle driver compiled in. I tried to bisect that failure, but came up with 72103bd1285211440621f2c46f4fce377584de54 seems unlikely to be right :) (as it is a virtio update)

(as I mistakenly commented on another bug)

pm_test shows everything good - devices, core, everything passes. But when I set pm_test to none, it fails to resume.

This should be fixed in the just-released upstream 3.5 kernel. From the changelog:

author Deepthi Dharwar
Mon, 25 Jun 2012 21:59:54 +0000 (23:59 +0200)
committer Rafael J. Wysocki
Wed, 27 Jun 2012 18:18:53 +0000 (20:18 +0200)
commit 75cc52358799bd6001e7d1a47847f997f5ae99f0
tree 3e8a4c0d94b4a4c7881f77404841d65de4370276
parent 1f758b23177d588a71b96ad02990e715949bb82f

PM / ACPI: Fix suspend/resume regression caused by cpuidle cleanup.

Commit e978aa7d7d57d04eb5f88a7507c4fb98577def77 ( cpuidle: Move
dev->last_residency update to driver enter routine; remove dev->last_state)
was breaking suspend on laptops, as reported in the below link
- https://lkml.org/lkml/2011/11/11/164

This was fixed in commit 3439a8da16bcad6b0982ece938c9f8299bb53584
(ACPI / cpuidle: Remove acpi_idle_suspend (to fix suspend regression)
by removing acpi_idle_suspend flag.
- https://lkml.org/lkml/2011/11/14/74

But this did fix did not work on all systems
as Suspend/resume regression was reported on Lenovo S10-3
recently by Dave.
- https://lkml.org/lkml/2012/5/27/115
It looked like with commit e978aa7d broke suspend and
with commit 3439a8da resume was not working with acpi_idle driver.

This patch fixes the regression that caused this issue
in the first place. acpi_idle_suspend flag is essential on
some x86 systems to prevent the cpus from going to deeper C-states
when suspend is triggered ( commit b04e7bdb984 )
So reverting the commit 3439a8da is essential.

By default, irqs are disabled in cpu_idle arch specific call
and re-enabled in idle state return path . During suspend,
the acpi_idle_suspend flag is set, which
prevents the cpus from going to deeper idle states,
it is essential to enabling the irqs in this return path too.

To address the suspend issue,
we were not re-enabling the interrupts while returning from
acpi_idle_enter_bm() routine if acpi_idle_suspend flag is set.
and this caused suspend failure.

In addition to the above, to improve the readability of the code,
return of -ENIVAL is replaced with -EBUSY in acpi_idle_suspend
return path. Implying that the system is currently busy when suspend
is in progress, which prevents the cpus from entering deeper C-states.

Reported-and-Tested-by: Dav Hansen
Tested-by: Preeti Murthy
Signed-off-by: Deepthi Dharwar
Reviewed-by: Srivatsa S Bhat
Signed-off-by: Rafael J. Wysocki

Quoting madbiologist (<email address hidden>):
> This should be fixed in the just-released upstream 3.5 kernel. From the
> changelog:

Terrific! I can't wait to test this in precise or quantal.

The 3.5-final kernel is now available in Quantal - see https://launchpad.net/ubuntu/+source/linux

Hi, I am trying Ubuntu 13.04 on My lenovo s10-3 and resume from suspend isn't working. I tried the options nohpet, intel_idle.max_cstate=0, also intel_idle.max_cstate=3 which I found somewhere on the internet and GRUB_CMDLINE_LINUX="resume=/dev/sdXX" but with no success. What Can I do next?

Dimitris - Suspend and resume should be working now on the Lenovo S10-3 without setting any options. If it doesn't, please file a new bug report so that we can get your system logs and system info. Feel free to mention the new bug number here.

Dimitris,
Ubuntu 13.04 also fails to resume on my Lenovo Ideapad S10-3.
However, if I update the kernel with one from upstream,
or install the Ubunto 13.10 daily build, it works for me:

https://bugzilla.kernel.org/show_bug.cgi?id=21952#c66