On Mon, Mar 16, 2009 at 2:40 PM, Larry Finger <Larry.Finger@xxxxxxxxxxxx> wrote: > My system says that there are 6172 commits between 2.6.29-rc8 and 2.6.28, thus > it will take roughly 13 kernel builds to bisect the problem. I had used a "poor man's git bisect" system once or twice: get a couple of months of daily compat-wireless tarballs, and doing manual bisect to find the two tar balls which results in the regression, then look up the release tags inside and extract the patches from wireless git (it is about 40 daily) then apply them in sequence, etc. The beauty of this scheme is that (1) installing/changing/switching between compat-wireless snapshot does not require a reboot - you just need to give up wireless connectivity for a moment during the switch, (2) building compat-wlreless is a lot faster than building whole kernel trees, (3) particularly if you don't have or don't intend to clone the whole of wireless git (a few hundred MB), the tarballs are relatively small - and just known which two (and their release tags) spans the regression would narrow the problem down to about 40 changes, many of them are obviously irrelevant, so this info could be useful to the developers. The release tags (*-release at the top of the tarball) are at the top of the unpacked tar balls. This process assumes that one can find a sufficiently old compat-wireless snapshot which did not have the problem, and a sufficiently new one which has it... -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
