Bug#656433: [3.1.5 -> 3.1.6 regression] Thinkpad X220 fails to wake up after hibernate-ram

[Jonathan Nieder <jrnieder@gmail.com>]

Hi,

Paul Seyfert wrote:

> I suspended my system with hibernate-ram. Opening the notebook later did not
> return me to my session (as desired). Instead after ~1 second I see the power
> LED turning off and hear the harddrive spin down. ~1 further second later, all
> LED light up (like they do if I turn the system on), the harddrive spins up
> shortly until everything shuts down again. Seems like the system is in a loop
> of turning on and off again every 2 seconds.
>
> The only way I found to exit this loop was removing the power supply and the
> battery (power button did not help).
> After downgrading to 3.1.5 the system wakes up as it should.

Can you bisect?  It works like this:

0. Install relevant tools: apt-get install git build-essential

1. Grab the stable kernel.

   git clone -o stable \
     git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git \
     linux

 If you already have a clone of Linus's tree, just add the relevant
 branches to it instead.

   cd linux
   git remote add -f stable \
     git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

2. Make sure you can reproduce the bug with v3.1.6.

   git checkout v3.1.6
   cp /boot/config-$(uname -r) .config; # current configuration
   make localmodconfig; # optional, minimize configuration
   make deb-pkg; # add -j<num> to speed up by using multiple CPUs
   dpkg -i ../<name of package>; reboot; test test test

3. Make sure you can reproduce the lack of bug with v3.1.5.

   git checkout v3.1.5
   make silentoldconfig; # reuse configuration
   make deb-pkg; # optionally with -j<num>
   dpkg -i ../<name of package>; reboot; test test test

4. If v3.1.6 reproduced the problem and v3.1.5 did not, record that:

   git bisect start
   git bisect good v3.1.5
   git bisect bad v3.1.6

 Git checks out a revision halfway between to test.

   make silentoldconfig; # reuse configuration
   make deb-pkg
   dpkg -i ../<name of package>; reboot; test test test
   cd ~/src/linux
   git bisect bad; # if it reproduces the problem
   git bisect good; # if suspend-to-ram works fine
   git bisect skip; # if some other problem makes it hard to test

5. Git checks out a revision halfway between to test.  Rinse and
   repeat until it finds the "first bad commit" or until bored.

At any step you can run "git bisect visualize" if the gitk package
is installed to see the regression range narrowing.  Even a few
rounds can be very helpful in narrowing down which patch introduced
the bug; one way to report partial results is to send "git bisect log"
output.

I'd also be interested in full "dmesg" output from booting an affected
kernel and booting and suspending an unaffected one.  By the way, is
this reproducible without the virtualbox driver?

Thanks for reporting.

Sincerely,
Jonathan