[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#622259: resuming from hibernation sometimes fails on eeepc 1002HA



forwarded 622259 https://bugzilla.kernel.org/show_bug.cgi?id=41982
quit

Frédéric Boiteux wrote:

>   Robert already did tests very quickly, but I'll try also to give some
> info : I've tried 2.6.39-bpo.2-686-pae, making 4 hibernations with some
> pauses between them, and it worked each time (the bug wasn't easily
> reproductible, but usually appeared in the 1 to 4 hibernations
> attempts).
>   I remember I did test some 2.6.33 kernel revisions, with the same bug
> always found. I'll try to compile a pristine 2.6.32.45 to test it, but
> as I identified the culprit patch, it was in the vanilla kernel also,
> so I don't think it could change something...

No need --- Robert already did enough.

Actually, it would be interesting to find how new the kernel has to be
to avoid this bug.  That is, first try v2.6.35.14 and then "bisect the
fix":

  apt-get install git-core build-essential
  git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
  cd linux
  git tag culprit v2.6.37-rc1~205^2

  git checkout v2.6.36-rc4
  git merge culprit
  make localmodconfig; # minimal configuration
  make deb-pkg; # add -j<n> for parallel build
  dpkg -i ../<name of package>
  ... test test test ...

For the sake of concreteness, let's say v2.6.35.14 triggers the
problem but v2.6.36-rc4 + culprit doesn't.  Then initialize the
bisection using the first "bad" and last "good" commits:

  # This is a little weird.  "bad" means fixed.  "good" means broken.
  git bisect start v2.6.36-rc4 v2.6.35

And run a round:

  # Git checks out a version half-way between.  Apply the fix:
  git rev-list v2.6.36-rc4..culprit |
  while read cmit
  do
	git cherry-pick --no-commit $cmit || break
  done
  make silentoldconfig; # reuse configuration
  make deb-pkg
  dpkg -i ../<name of package>
  ... test test test ...
  cd ~/src/linux
  git bisect good;	# if it reproduces the failure to resume
  git bisect bad;	# if it seems perfectly functional
  git bisect skip;	# if some other bug makes it hard to test

So far, so usual, except for the new meanings for "good" and "bad".
Repeat until bored as usual. :)  Even a couple of rounds could help a
lot in narrowing down what change is missing.



Reply to: