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