On Thu, 9 Oct 2014, Mark Knibbs wrote: > I finally finished doing git bisect between 2.6.33 and 2.6.34. Sadly I'm > not really any the wiser, since the result looks pretty bogus. > > The supposedly-bad commit was: > 002345925e6c45861f60db6f4fc6236713fd8847 > syslog: distinguish between /proc/kmsg and syscalls > > There doesn't seem to be anything in that which could cause the problem; > perhaps something went wrong with the bisection? That commit doesn't > cleanly revert with later kernel versions. Git bisect isn't always reliable. You need to validate the final result by testing both the first bad commit and its parent (the last good commit). If their behaviors are different then you can conclude that the bad commit caused the difference. Sometimes the nature of the cause isn't readily apparent. For example, a change in one part of the kernel may result in a subtle timing difference that has an unexpectedly large effect on another part of the kernel. Alan Stern -- 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
