On Sun, Dec 29, 2013 at 02:49:16PM -0500, Gene Heskett wrote: > On Sunday 29 December 2013, Jason Cooper wrote: > >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'. > I did do that, the above report was the final of about 8 or 9 reboots after > telling it each time "git bisect bad".
I'm not trying to insult you, but just to be clear: After each reboot, was the patch_level reported wrong? If it was correct, you needed to run 'git bisect good' instead. I can't think of any other reason why it would finger the commit above. > These will all be 32 bit PAE kernels though as I don't know how to convert > it to 64 bit when a make xconfig doesn't give me that option. Ahhh, then you should start with i386_defconfig. You can see the full list at arch/x86/configs/. I assumed you were running 64bit, my fault. thx, 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/
