Messages in this thread | | | From | Gene Heskett <> | Subject | Re: [BUG BISECTED FAILED] Phenom microcode revision mis-identified | Date | Sun, 29 Dec 2013 15:17:10 -0500 |
| |
On Sunday 29 December 2013, 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 >>> ><tigran@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+kernel@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". > >And that "reset" is what I did not do just now. Instead, I went directly >to git checkout v3.8.2, then moved a known good pair of configs (which >now give me no option to build the 64 bit kernel as the first line in a >make xconfig) > >Then, because it was still building a bunch of stuff that aren't >applicable to my hardware, so I stripped several pages worth of modules, >and a new 3.8.2 from linux-stable is building now. But it will take 20 >minutes longer. If this doesn't work, then I'll copy these .configs >back to that tarball tree and try that. One things is for sure, I'm >keeping my coffee warm on that phenom. ;-) > >If it then works for the tarball built kernel, then I'll do the git >bisect reset and restart, doing the bisect all over again. But this >time I'll start it at a checkout v3.8.2, git bisect good (if it works >now) and go toward v3.8.3 bad. > >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. > >Thanks Jason. > >>Jason.
Ok, next reboot to 3.8.2, built from linux-stable, checkout v3.8.2, using the .config files from my tarball built 3.8.2 which works: gene@coyote:~/src/linux-3.12.0$ dmesg|grep -A2 microcode 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 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
So this works, leaving something in the much smaller x86_64defconfig as the culprit, So now to the bisect reset and restart the bisect moving forward. More later I expect.
Thanks and Cheers, Gene
| |