On Sun, Dec 29, 2013 at 12:47:02PM -0500, Gene Heskett wrote: > On Sunday 29 December 2013, Gene Heskett wrote: > >Resend, incorrect subject line > > > >Here is the copy/paste of the final git bisect bad report: > > > >First, the reason for the bisect: > >gene@coyote:~/linux-stable$ dmesg | grep -A2 microcode > >[ 0.518304] microcode: CPU0: patch_level=0x01000065 > >[ 0.518396] microcode: CPU1: patch_level=0x01000065 > >[ 0.518498] microcode: CPU2: patch_level=0x01000065 > >[ 0.518593] microcode: CPU3: patch_level=0x01000065 > >[ 0.518745] microcode: Microcode Update Driver: v2.00 > ><tig...@aivazian.fsnet.co.uk>, Peter Oruba > > > >The output above should have in each cpu case, a second, or final line > >showing a patch level 0x0100083 in all cases. > >This failure is on an AMD phenom 9550 equipt machine. > > > >I can and have built from the tarball pull, a 3.8.2 which does work > >correctly. The tarball build of 3.8.3 fails as above, and a tarball > >build of 3.12.6 still fails. > > > >gene@coyote:~/linux-stable$ git bisect bad > >908e88f285b909011dc7dbce5abaacf123f2f68d is the first bad commit > >commit 908e88f285b909011dc7dbce5abaacf123f2f68d > >Author: Russell King <rmk+ker...@arm.linux.org.uk> > >Date: Mon Feb 25 16:09:12 2013 +0000 > > > >I'll next do a "git checkout v3.8.2" to double check that it works.
Please re-read the manpage for git bisect, particularly the section "Basic bisect commands". You need to keep repeating building and booting the kernel, execute 'git bisect [good|bad]', as git bisect checks out different commits to try. Depending on the number of commits, it can take 7 to 10 iterations before it nails it down to the bad commit. $ git log --oneline v3.8.2..v3.8.3 | wc -l 103 So you started at v3.8.3, said v3.8.2 is good. git bisect will then checkout a commit in the middle (of the 103 commits to choose from). You need to build that kernel, boot it, and see if the error occurs. Then, type 'git bisect [bad|good]' depending on what happened. When that command returns, it has checked out a different commit between v3.8.2 and v3.8.3. Build, boot, and run 'git bisect [good|bad]' depending on if the patch_level was reported properly. Repeat until it reports nothing left to test. > FWIW, a git checkout v3.8.2 also fails, so next I'll move my working > tarball build .configs into that tree & see if it works. If the config you started with worked for v3.8.2 and didn't for v3.8.3, keep using it. > This is getting stranger, a checkout v3.8.2 is supposed to match the > tarball I got from kernel.org isn't it? Yes, see above. As soon as you started the bisection process, you were no longer on version 3.8.2 or 3.8.3, but somewhere in between. That's what's supposed to happen. Once you run enough iterations to get nothing left to test, record the commit it identified, and run 'git bisect reset'. hth, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
