tags 635575 + moreinfo
quit
Hi Lars,
Lars Boegild Thomsen wrote:
> After update from 2.6 kernel to 3.0 my Idepad S10-3 will not wake up after
> sleep. Back to latest 2.6 kernel works fine.
Thanks for reporting it. Basic questions:
- could you attach "dmesg" output from booting the latest good and
first bad kernel you know of?
- the information from
sh /usr/share/bug/linux-image-3.0.0-1-amd64/script 3>&1
would also be helpful.
- what is the lack-of-wakeup process like --- does it make any noise?
do LEDs show anything happening? do caps lock and num lock work?
can you use ctrl-alt-del or alt-sysrq S+U+B to reboot afterwards?
Do logs say anything about what happened on the next boot?
- does it fail to wake up 100% of the time or only sometimes?
- any other weird symptoms?
If none of the above yields any hints, your best bet is probably to
bisect to find which upstream change introduced the problem. It works
like this:
1. Build the latest upstream version and test it.
# apt-get install build-essential git-core
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$ cd linux
$ make localmodconfig; # minimal configuration
$ make deb-pkg
# dpkg -i ../<name of package it generated>
# reboot
If that version suspends and resumes without trouble, declare victory.
Maybe the bug was fixed upstream or maybe the .config left out some
problematic driver; either way, we'll have something to work with.
2. Begin the bisection process.
$ git bisect start v3.0 v2.6.39
Git checks out a version half-way between to test.
$ make silentoldconfig; # reuse configuration
$ make deb-pkg
# dpkg -i ../<name of package generated>
# reboot
... test test test ...
$ cd ~/src/linux
$ git bisect good; # if it suspends without trouble
$ git bisect bad; # if it fails like v3.0 did
$ git bisect skip; # if some other problem makes it hard to test.
Then git checks out another version to test.
3. Repeat until bored:
$ make silentoldconfig; # reuse configuration
$ make deb-pkg
# dpkg -i ../<.deb filename>
# reboot
... test ...
$ git bisect good / bad / skip
Eventually, it finds the "first bad commit". To watch the regression
range get narrower before then, you can use "git bisect visualize" if
the gitk package is installed. And "git bisect log" summarizes the
results in case you want to stop before pinning it to a single commit.
Hope that helps, and sorry I don't have any better ideas.
Regards,
Jonathan
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110728003739.GC22001@elie
