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 <tig...@aivazian.fsnet.co.uk>, > Peter Oruba > > gene@coyote:~/linux-stable$ git bisect good > 1a45c310b2102c58e37f84abba67fe21d5d6edcf is the first bad commit > commit 1a45c310b2102c58e37f84abba67fe21d5d6edcf > Author: Greg Kroah-Hartman <gre...@linuxfoundation.org> > 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 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/
