Romano Giannetti wrote:
> This was what I did in my (in the end almost successful) bisecting when
> trying to find the mmc problem (see the thread named "2.6.24-rc1 eat my
> SD card"). This is true in theory, but it has some problem. The "this
> commit does not compile is the easiest and in man git-bisect it's
> explained how to solve it. The changes in .config options, added or
> removed, are another problem when jumping back and forth from version.
>
> The main problem I had, and that stopped me to arrive to a definite is
> this situation:
[...]
> (d was the series to change drivers to use sg helpers, and g was a "fix
> fallout from sg helpers" patch). Now I have a series of kernels (d, e,
> f) that did not work at all and so I cannot mark them good or bad. With
> the number of patches added in the free-for-all week, this is a very
> probable scenario. There is a way out from this using bisect?
I think there are three strategies you can use in this case:
- create a kernel config that is as simple as possible, but still supports
your hardware and reproduces your problem; a simpler config will often
avoid compilation issues in parts of the kernel that you're not using
anyway and has the benefit of speeding up the compiles too
- if you know/suspect in what part of the tree the bug is, first limit the
bisection to that; you will have to verify that you did indeed find the
correct (broken) change by doing a compile for the "last good commit + 1"
- if you find a broken commit, use 'git-reset --hard' to try to jump past
the bad set of commits, but of course that does not help in the case:
g version-bad
f unrelated bug corrected
e
d the broken commit that caused your problem
c
b unrelated bug that breaks compilation or system introduced
a version-good
in that case the best you can reasonably be expected to do is report that
you narrowed it down to "between a and g" and leave the rest to the
developers
Cheers,
FJP
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
