Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51

[Jonathan Nieder <jrnieder@gmail.com>]

Hi Octavio,

Quick instructions:

Alan Stern wrote:

> It might be worthwhile tracking down the reason for the immediate 
> wakeup.  If you build a kernel with CONFIG_USB_DEBUG enabled, what 
> shows up in /sys/kernel/debug/usb/ohci/*/registers?  And what shows up 
> in /sys/kernel/debug/usb/devices?

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. fetch point releases:

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

3. configure, build:

	git checkout stable/linux-3.2.y
	cp /boot/config-$(uname -r) .config; # current configuration
	scripts/config --disable DEBUG_INFO
	make localmodconfig; # optional: minimize configuration
	scripts/config --enable USB_DEBUG
	make deb-pkg; # optionally with -j<num> for parallel build

4. test:

	dpkg -i ../<name of package>; # as root
	reboot
	mount -t debugfs debugfs /sys/kernel/debug
	grep . \
		/sys/kernel/debug/usb/ohci/*/registers \
		/sys/kernel/debug/usb/devices

> Also, what does the "lspci -vv" output show for the controller if you 
> run it with superuser permissions?

This one's easier (no rebuild necessary).

>> For kernel 3.4, I'll break it into two parts: the going asleep and the
>> wakening back.
[...]
>> For the wakening back part, with both settings the PC locks up requiring a
>> mechanical (power supply switch) power cycle to bring the computer back.
>> Not even the 5-sec power button cycle helps. I guess this is a different
>> bug, so I'll try to troubleshoot it and open a different one.
[...]
> Maybe you can do a git bisection to find what changed between 3.2 and 
> 3.4 to cause this behavior.

This works like so:

	cd linux
	git bisect start v3.4.1 stable/linux-3.2.y

	# git checkouts out a version halfway between to test, so try it:
	make deb-pkg; # maybe with -j4
	dpkg -i ../<name of package>; # as root
	reboot
	... test test test ...

	cd linux
	git bisect bad; # if resume locks up
	git bisect good; # if it resumes fine
	git bisect skip; # if some other bug makes it hard to test

	# git checks out a version halfway between to test, so:
	make deb-pkg; # maybe with -j4
	dpkg -i ../<name of package>; # as root
	... and so on ...

After enough cycles it will find the "first bad commit".  If you get
bored before then:

	# if the gitk package is installed,
	# to see the current regression range narrowing at any step
	git bisect visualize

	# to print a log of tests you've run so far, which lets someone
	# else pick up where you left off
	git bisect log

	# to abandon the bisect
	git bisect reset

See [1] for details.

Hope that helps,
Jonathan

[1] http://git-htmldocs.googlecode.com/git/git-bisect-lk2009.html