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 from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
