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

Bug#670958: [2.6.37 -> 2.6.38-rc6 regression] udev/power_supply battery oscilates between remove and add



Adrian Fita wrote:

> Hi. I tracked the regression between kernel v. 2.6.37-2 [1] (not
> happening) and v. 2.6.38~rc6-1~experimental.1 [2] (happening).
>
>   1: http://snapshot.debian.org/package/linux-2.6/2.6.37-2/
>   2: http://snapshot.debian.org/package/linux-2.6/2.6.38~rc6-1~experimental.1/
>
> What do you recommend next?

Nice.  That narrows it down to one of 104 patches, which means
7 rounds of bisection would narrow it down to a single patch:

 0. prerequisites:

	apt-get install git build-essential

 1. get the kernel history, if you don't already have it:

	git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

 2. make sure the upstream kernel reproduces the bug:

	cd linux
	cp /boot/config-$(uname -r) .config; # current configuration
	scripts/config --disable DEBUG_INFO
	make localmodconfig; # optional: minimize configuration
	make deb-pkg; # optionally with -j<num> for parallel build
	dpkg -i ../<name of package>; # as root
	reboot

    Hopefully it does.  So:

 4. make sure the older kernel does not reproduce the bug:

	cd linux
	git bisect start -- drivers/acpi
	git bisect bad v2.6.38-rc6
	git checkout v2.6.37
	make silentoldconfig; # reuse configuration
	make deb-pkg; # maybe with -j4
	dpkg -i ../<name of package>; # as root
	reboot
	... test test test ...
	git bisect good; # mark v2.6.37 as good

 5. a version half-way between is automatically checked out to test:

	make silentoldconfig; # reuse configuration
	make deb-pkg; # maybe with -j4
	dpkg -i ../<name of package>; # as root
	reboot
	... test test test ...

	git bisect bad; # if it reproduces the bug
	git bisect good; # if it works nicely
	git bisect skip; # if some other bug makes it hard to test

If you go through step 5 enough times, it will reveal the "first bad
commit".  If you get bored before then, running "git bisect log" will
produce a log of the versions you have tested to allow someone else to
pick up where you left off.  If the gitk package is installed, at any
step you can run "git bisect visualize" to watch the regression range
narrowing.

Hope that helps,
Jonathan



Reply to: