On Sunday 29 December 2013, Jason Cooper wrote: >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?
Yes, that was my first check after the reboot, grepping dmesg to see if it worked. If it didn't, I told it "git bisect bad", built and booted the next step in the bisect. I cheated, and now have my makeit script tracking the version. :) >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. > This first bisect was started at 3.8.3, working toward 3.8.2 as good. Even the last, git said final build, was bad. I agree, the text of that patch should have had no connection to my problem. But the first build going forward from 3.8.2 to 3.8.3, is good. So I am continuing forward, although as I see the compiler beefing about something, and its not something I need, it will not be in the next build as its just gingerbread anyway. The build I am booted to ATM s/b the halfway to 3.8.3 point, and it works: microcode: CPU0: patch_level=0x01000065 microcode: CPU0: new patch_level=0x01000083 microcode: CPU1: patch_level=0x01000065 microcode: CPU1: new patch_level=0x01000083 microcode: CPU2: patch_level=0x01000065 microcode: CPU2: new patch_level=0x01000083 microcode: CPU3: patch_level=0x01000065 microcode: CPU3: new patch_level=0x01000083 microcode: Microcode Update Driver: v2.00 <tig...@aivazian.fsnet.co.uk>, Peter Oruba Continuing with the bisect... >> 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. Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> Never frighten a small man -- he'll kill you. A pen in the hand of this president is far more dangerous than 200 million guns in the hands of law-abiding citizens. -- 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/
