On Tue, Aug 18, 2009 at 2:15 PM, Pavel Roskin<pro...@gnu.org> wrote: > On Tue, 2009-08-18 at 14:07 -0700, Luis R. Rodriguez wrote: >> On Tue, Aug 18, 2009 at 2:04 PM, Pavel Roskin<pro...@gnu.org> wrote: >> > On Tue, 2009-08-18 at 23:46 +0530, Kunal Gangakhedkar wrote: >> >> > Note that Michael noticed the performance degradation. That's another >> >> > target for bisection, whether it's related or not. >> >> >> >> Any way we can help debug this issue? >> >> It gets really annoying when the driver goes berserk in the middle of a >> >> big >> >> file transfer - even on LAN. :( >> > >> > If an older driver didn't have that problem, you can use the git bisect >> > command to find which change introduced the slowdown, provided that you >> > can detect it reliably. >> >> But note: wireless-testing sucks for bisecting, so you may want to >> reproduce on the wireless-next-2.6 tree. >> >> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next-2.6.git;a=summary > > It's described as "Linville's 2.6.26 wireless networking development > tree", but the Makefile indicates 2.6.31-rc5. Perhaps the description > needs updating?
Adding John, John it seems your linux-next-2.6 tree discription is stuck on 2.6.26. > Anyway, why is it better for bisecting? Because to help developers not have to do: git branch -m poo git checkout -b master origin/master # Then apply patches manually Instead of the better rebasing: git branch -m save-my-stuff git checkout -b master origin/master git checkout save-my-stuff git rebase master john reverts his patches on wireless-testing before rebasing to Linus' tree. There may be some other added benefit other than helping us rebase cleanly, not sure. But I do remember before that I never was able to rebase my patches, and now rebasing works quite nicely. Luis _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
