Re: [BUG BISECTED FAILED] Phenom microcode revision mis-identified

From: Gene Heskett
Date: Sun Dec 29 2013 - 16:24:37 EST

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
>> >> ><tigran@xxxxxxxxxxxxxxxxxxxx>, 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@xxxxxxxxxxxxxxxx>
>> >> >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 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 <tigran@xxxxxxxxxxxxxxxxxxxx>,
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.

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 <>

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at