[BUG BISECTED]

[BUG BISECTED]

[Gene Heskett]

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.

Cheers, Gene

Re: [BUG BISECTED FAILED]

[Gene Heskett]

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.

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.  This is getting 
stranger, a checkout v3.8.2 is supposed to match the tarball I got from 
kernel.org isn't it?

Cheers, Gene

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

[Jason Cooper]

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

hth,

Jason.

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

[Gene Heskett]

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.


Cheers, Gene

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

[Gene Heskett]

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

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

[Jason Cooper]

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@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".

I'm not trying to insult you, but just to be clear: After each reboot,
was the patch_level reported wrong?  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.

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

thx,

Jason.

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

[Gene Heskett]

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@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".
>
>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@aivazian.fsnet.co.uk>, 
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.
>
>thx,
>
>Jason.


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 <http://geneslinuxbox.net:6309/gene>

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.

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

[Gene Heskett]

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@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".
>
>I'm not trying to insult you, but just to be clear: After each reboot,
>was the patch_level reported wrong?  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.
>
>> 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.
>
>thx,
>
>Jason.

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@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 <gregkh@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.

Cheers, Gene

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@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 <gregkh@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.

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

[Gene Heskett]

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@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 <gregkh@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?
>
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.

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

Cheers, Gene