Bug#665881: [wheezy] module ath5k is blocking wlan-card

[Jonathan Nieder <jrnieder@gmail.com>]

fixed 665881 linux-2.6/3.3~rc6-1~experimental.1
found 665881 linux/3.2.35-2
# not fixed in 3.2.y yet
tags 665881 - fixed-upstream
quit

Hans-J. Ullrich wrote:

> I installed linux-image-3.3.0-rc6-amd64_3.3~rc6-1~experimental.1_amd64.deb 
> from snapshots.debian.org, and its headers, but the bug never appeared.
>
> I did almos 10 - 15 rebootsx with no appearence of the bug.
>
> Then I started 3.2 kernel and the bug appeared again.

Thanks, Hans.  Marking accordingly so we don't forget.

Am I correct in assuming the 3.2 kernel in question is 3.2.35-2?

The next step is for us to ferret out another upstream patch to test.
If you're bored before then, here are instructions for performing a
"reverse bisect" to find when the fix seems to have been introduced.
These instructions will probably be confusing: remember that a "good"
kernel is one that successfully reproduces the bug, while a "bad" one
is one that does not reproduce it.

0. get the kernel history, if you don't already have it:
	git clone \
	  https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git

1. initialize the bisection, configure, build, test:
	cd linux
	git bisect start
	git checkout v3.2
	cp /boot/config-$(uname -r) .config; # current configuration
	make localmodconfig; # optional: minimize configuration
	make deb-pkg; # optionally with -j<num> for parallel build
	dpkg -i ../<name of package>; # as root
	reboot
	...test test test ...

  Hopefully it reproduces the bug, so:

	git bisect good; # it reproduced the bug!

2. confirm upper bound:
	cd linux
	git checkout v3.3-rc6
	make deb-pkg; # maybe with -j4
	dpkg -i ../<name of package>; # as root
	reboot
	... test test test ...

   Hopefully it does not reproduce the bug, so:

	cd linux
   	git bisect bad

3. A version half-way between is automatically checked out for
   testing.  Test:

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

   Record the result:

	cd linux
	git bisect good; # if it reproduces the bug
	git bisect bad; # if rebooting a few times does not reproduce it
	git bisect skip; # if some other bug makes it hard to test

   Repeat.

Eventually git tells you the "first bad commit", which is the patch
that alleviated symptoms.  If the "gitk" package is installed, you can
see the range of candidates at any step by running "git bisect
visualize".  To stop early, run "git bisect log", which produces a log
that others can use to see your results so far or pick up where you
left off.  Even a few rounds can narrow down the search by quite a
bit.

You can read more about the "git bisect" tool at
http://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html
but remember, for us a "bad" commit is a commit _not_ exhibiting the
bug and a "good" commit is one that successfully reproduces the bug.

Thanks again for your patience.  Hopefully we will have a better idea
of what's going on soon.

Regards,
Jonathan