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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org