Messages in this thread | | | Date | Thu, 17 Dec 2009 14:43:04 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: DMA cache consistency bug introduced in 2.6.28 (Was: Re: [Fdutils] Cannot format floppies under kernel 2.6.*?) |
| |
On Thu, 17 Dec 2009, Alain Knaff wrote: > [...] > > You'd need a git tree that contains both the working and non-working > > versions, and then literally just do > > > > git bisect start > > git bisect good <known good version number here> > > git bisect bad <known bad version here> > > > > and it will give you a commit to try. Compile, test, see if it's good or > > bad, and do > > > > git bisect [good|bad] > > > > depending on the result. Rinse and repeat (depending on how tight the > > initial good/bad commits were, it will need 10-15 kernel tests). > > ... and how do I check out the most recent good / oldest bad kernel for > compilation?
'git bisect' does all that for you. You don't need to check out the kernels you mark good or bad - git will just calculate the commit graphs, and pick a commit that is in the "middle" between them, and check out that commit.
> > So after a successful bisect, it is usually a good idea to try to go back > > to the original known-bad kernel, and then revert the commit that was > > indicated as the bad one (assuming the revert works - it could be that the > > bad one ends up being fundamental to other commits after it), and test > > that yes, that really fixes the bug. > > What command lines would I use for that revert?
git revert <sha1-that-git-bisect-reported>
but even if that revert isn't successful, just the bisection result will be very interesting (assuming it all looks sane, of course - as mentioned, sometimes bisect results get screwed up because the bug isn't entirely reproducible due to timing etc).
Linus
| |