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

[Jason Cooper]

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?

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?

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/