Re: [BUG BISECTED] Phenom microcode revision mis-applied

From: Gene Heskett
Date: Mon Dec 30 2013 - 09:56:52 EST

On Monday 30 December 2013, Jason Cooper wrote:
>On Sun, Dec 29, 2013 at 10:02:02PM -0500, Gene Heskett wrote:
>> Finally done with the forward bisect:
>> gene@coyote:~/linux-stable$ 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@xxxxxxxxxxxxxxxxxxxx>, Peter Oruba
>> gene@coyote:~/linux-stable$ git bisect good
>> 1a45c310b2102c58e37f84abba67fe21d5d6edcf is the first bad commit
>> commit 1a45c310b2102c58e37f84abba67fe21d5d6edcf
>> Author: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
>> Date: Thu Mar 14 11:27:14 2013 -0700
>> Linux 3.8.3
>> :
>> :100644 100644 20d53183508e8f49253ec7e5ede0a12b4556fc32
>> :8c49fc9b45a993a8e78cde4f9621b727b9121eac M Makefile
>> The v3.8.3 Makefile? Its just about the only thing that would be bad
>> every step from v3.8.3 to v3.8.2, and good all the way from v3.8.2 to
>> the last patch that made the v3.8.3 release. Bisected twice, once in
>> each direction.
>When it works, which CONFIG_MICROCODE* options are set? And unset when
>it fails?
That is not being intentionally changed. But this line I see very early in
the build trace:

scripts/kconfig/conf --silentoldconfig Kconfig

seems to be undoing any changes I make with a make xconfig. I must have
turned off the intel video and turned on the nouveau 15 times before it
finally stuck, just one example of many.

>Also, what is the driving problem here? I know the log entry 'new
>patch_level=...' is missing, but what regression are you seeing that is
>caused by not updating the microcode?

On this system, when the microcode has not been updated, eg the "new patch
level" line is missing in the above report, then I have stalls of up to 2
or 3 minutes in the kmail composer, which is by far the busiest application
here, like kmail has gone away doing something else. But if it is, then
htop can't see it, and all of kmails background processes have been
relegated to fetchmail/procmail/spamassassin/clam here for years for
exactly that reason. But the cpu's aren't showing a load in the gkrellm
display, or in htop, both of which continues to function normally, and I
can switch workspaces and all is well but come back to the kmail screen and
the keyboard is dead, and the mouse pointer disappears when over the
composer window. When the report says it worked as above does, I don't get
this oddity. I would almost say its an interrupt problem, except that when
it "wakes up" again, it will play catchup with what I typed. But I don't
type all that well blind. :)

So last night, finding it hard to believe the 3.8.3 makefile could be it, I
started a new bisect, this time with 3.8.2 good, 3.8.4 bad, and will see
what I get this time. With my "makeit" script now tracking the version, it
Just Works(TM), so all I have to do is reboot to the kernel I have it now
reporting as it exits.

I know, this doesn't make sense, but I have been living with it since I
built this box when a Phenom 9550 was cutting edge! Thats why I will do
yet another bisect. If it nails the 3.8.3 makefile again, then the same
error still exists in 3.12.6, it has never again successfully applied the
AMD microcode since. But I have not built the intervening versions either
so that is not a blanket statement. So I'll be back when i have the final
result of this new bisect again.

Thanks for your patience Jason, there are times when I am fresh out.

Cheers, Gene
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