Re: AMD microcode fails to update with v3.8.3 and newer, bisect failed

[Gene Heskett]

On Thursday 02 January 2014, Gene Heskett wrote:
>On Thursday 02 January 2014, Ken Moffat wrote:
>>On Thu, Jan 02, 2014 at 12:24:56AM -0500, Gene Heskett wrote:
>>> On Wednesday 01 January 2014, Ken Moffat wrote:
>>> >On Thu, Jan 02, 2014 at 04:08:15AM +, Ken Moffat wrote:
>>> >>  Anyway, best of luck and I hope you get it sorted.
[...]
>My "makeit" script actually stores the .config as a config-$VER.gz in the
>boot, renaming an existing one to gz.old if its found.  But that was
>apparently overwritten more than twice while attempting the bisect.
>
>No progress today, I've been out playing small town broadcast engineer,
>the local AM'ers daytime transmitter put out about 1 kilgram of smoke at
>turn on this morning.  A gassy 807 took out a 10 henry choke in the
>power supply about 10kg, but now nice and toasty overdone.  Parts on
>order, but are up in PA, and this current snowstorm has PA in just about
>in a total lockdown. Might have it by Monday.
>
>Cheers, Gene

This morning I may have found a clue.  The last thing I did last night was 
to note that in the boots where it worked, the module microcode was a 
MODULE, not built in.  So I made a boot with only that change, after having 
built a previous boot with all the ext# stuff built in too.

I am booted to 3.12.6, 32 bit build on a phenom cpu, it IS recognizing all 
8Gb of my memory, and:

gene@coyote:~/src/linux-3.12.6$ dmesg|grep microcode
[   22.572212] microcode: CPU0: patch_level=0x0165
[   22.573242] microcode: CPU0: new patch_level=0x0183
[   22.573256] microcode: CPU1: patch_level=0x0165
[   22.573263] microcode: CPU1: new patch_level=0x0183
[   22.573273] microcode: CPU2: patch_level=0x0165
[   22.573281] microcode: CPU2: new patch_level=0x0183
[   22.573293] microcode: CPU3: patch_level=0x0165
[   22.573301] microcode: CPU3: new patch_level=0x0183
[   22.573377] microcode: Microcode Update Driver: v2.00 
, Peter Oruba

So the microcode updating does not work when built in.

So the $64k questions are, 1. does it work for anyone else when built in? 
and 2. is it supposed to?

Obviously if it is supposed to work, why not?  I'm not equipt to do much 
more than report.  The coal mines canary comes to mind.

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 

I'm not tense, just terribly, terribly alert!
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 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/

Re: AMD microcode fails to update with v3.8.3 and newer, bisect failed

[Gene Heskett]

On Thursday 02 January 2014, Ken Moffat wrote:
>On Thu, Jan 02, 2014 at 12:24:56AM -0500, Gene Heskett wrote:
>> On Wednesday 01 January 2014, Ken Moffat wrote:
>> >On Thu, Jan 02, 2014 at 04:08:15AM +, Ken Moffat wrote:
>> >>  Anyway, best of luck and I hope you get it sorted.
>> > 
>> > One further suggestion, since you appear to be at the "running
>> >
>> >round in circles" stage -
>> >
>> >1. Start with a good kernel.  In this case, I suppose 3.8.2 is the
>> >right place to begin.
>> 
>> That has since died, won't boot, don't recall changing a thing in the
>> .config either.
>
> That makes things harder.  Do you have any backups from when it
>booted ? (kernel, modules, and grub.cfg might all have been
>accidentally overwritten).
>
> To reply to your earlier post about a lack of local tarballs : try
>installing wget (if you don't already have it), or use a firefox
>variant on a desktop machine and then transfer it to the phenom.
>
> For convenience, I always download the 3.x.0 kernel as a tarball,
>and then 3.x.{1..n} as patches.  And I usually rename the directory
>as linux-3.x-stable so that I can remember what it is, and also so
>that it doesn't get overwritten if I untar a fresh copy for other
>reasons.  So, first I use 'head Makefile' to confirm the current
>version.  I then remove any stable patch using 'xzcat | patch -R
>-p1' so that I'm back to 3.x.0 and then apply the patch for the next
>version I want to test.
>
> Lots of possible variations on this exist, particularly when I'm
>bisecting.  The important thing is to have a process which works for
>you - for stable kernels, some people will prefer to use a fresh
>3.x.y tarball each time.
>
>> >2. But then change the .config to -
>> >
>> >2.1 ensure that your disk filesystems are built in - e.g. all of
>> >ext2, ext3, ext4 and anything else you know you are using.
>> 
>> Should I edit in the /etc/grub.d to remove the modprobe ext2, or will
>> it more or less silently shake its head and go on.
>
> I think the modprobe instructions in the grub files are used to
>ensure that grub can load its own modules before it tries to read
>the specified kernel.  So no, I would not change that.  The kernel's
>own modules (specifically ext2/3/4) are something else - without an
>initrd, the kernel needs the filesystem used for '/' to be built in.
>
> So : if the kernel starts to boot, the grub part is ok.
>
>> >Normally, only the fs for '/' needs to be built in, but you seem to
>> >have seen other issues so I would just build in everything you need.
>> >
>> >2.2 build in everything else you need to boot (normally, the disk
>> >controller(s) ) so that you don't need an initrd.
>> 
>> That would be forcedeath, nouveau, v4l1 and 2 and hda_audio for
>> starters.
>
> Nouveau and forcedeath will probably be convenient, but the rest
>ought to be ok as modules.  In this context, I mean whatever you need
>for the kernel to get to a position where it can load modules.  So,
>it needs the disk driver(s) and the root filesystem (where
>/lib/modules lives).
>
>> Since this kernel isn't near new enough for the config tricks
>> mentioned, maybe I'll see if the linux-stable I have can do a 3.11.0
>> checkout.
>> 
>> >2.4 for your convenience, ensure that you have enabled the config to
>> >be stored in /proc/config.gz - once you are building your own
>> >slimmed-down kernels, you probably won't want to mess about with
>> >distro "install" scripts so just copying the bzimage to
>> >/boot/vmlinuz-x.y.z, make modules_install, and editing
>> >/boot/grub/grub.cfg (yes, really!) will save a lot of time.
>> 
>> My present script does everything but edit grub.cfg.
>
>[...]
>
>> >3.  That might take two or three attempts to get to a good config,
>> >but after that you should be able to use the slimmer config (from
>> >zcat /proc/config.gz) to create .config for any newer version you
>> >want to test or bisect, and then just run make oldconfig before you
>> >build.
>> >
>> > Also, when you get back to bisecting, the version in the kernel
>> >
>> >Makefile might not be what you expect.  If in doubt, you can change
>> >it to something which doesn't overwrite any existing modules, e.g.
>> >3.8.bisect-1 etc.
>> 
>> Presently it uses a + sign for in between versions.
>
> I'm more familiar with bisecting in -rc versions : for those, the
>Makefile version will jump back to what it was when the code was
>developed.  Very confusing if you weren't expecting it.
>
>> > HTH
>> 
>> It will, if I don't lose my place...
>> 
>> >ط¤آ¸en
>> 
>> My "makeit" script does cd's here and there, so its vital that the
>> Makefile version matches the makeit version.  I've thought of that,
>> and fixed it in the copy I use to make a linux-stable install, but I
>> haven't moved that line of script into the tarball builds yet.
>
> I haven't bothered to script my own kernel builds/installs for many
>years - as you say, make sure everything matches.
>
>> Having an automatic increment, I could eventually fill up the /

Re: AMD microcode fails to update with v3.8.3 and newer, bisect failed

[Ken Moffat]

On Thu, Jan 02, 2014 at 12:24:56AM -0500, Gene Heskett wrote:
> On Wednesday 01 January 2014, Ken Moffat wrote:
> >On Thu, Jan 02, 2014 at 04:08:15AM +, Ken Moffat wrote:
> >>  Anyway, best of luck and I hope you get it sorted.
> >
> > One further suggestion, since you appear to be at the "running
> >round in circles" stage -
> >
> >1. Start with a good kernel.  In this case, I suppose 3.8.2 is the
> >right place to begin.
> 
> That has since died, won't boot, don't recall changing a thing in the 
> .config either.
> 

 That makes things harder.  Do you have any backups from when it
booted ? (kernel, modules, and grub.cfg might all have been
accidentally overwritten).

 To reply to your earlier post about a lack of local tarballs : try
installing wget (if you don't already have it), or use a firefox
variant on a desktop machine and then transfer it to the phenom.

 For convenience, I always download the 3.x.0 kernel as a tarball,
and then 3.x.{1..n} as patches.  And I usually rename the directory
as linux-3.x-stable so that I can remember what it is, and also so
that it doesn't get overwritten if I untar a fresh copy for other
reasons.  So, first I use 'head Makefile' to confirm the current
version.  I then remove any stable patch using 'xzcat | patch -R
-p1' so that I'm back to 3.x.0 and then apply the patch for the next
version I want to test.

 Lots of possible variations on this exist, particularly when I'm
bisecting.  The important thing is to have a process which works for
you - for stable kernels, some people will prefer to use a fresh
3.x.y tarball each time.
> >2. But then change the .config to -
> >
> >2.1 ensure that your disk filesystems are built in - e.g. all of
> >ext2, ext3, ext4 and anything else you know you are using.
> 
> Should I edit in the /etc/grub.d to remove the modprobe ext2, or will it 
> more or less silently shake its head and go on. 
> 
 I think the modprobe instructions in the grub files are used to
ensure that grub can load its own modules before it tries to read
the specified kernel.  So no, I would not change that.  The kernel's
own modules (specifically ext2/3/4) are something else - without an
initrd, the kernel needs the filesystem used for '/' to be built in.

 So : if the kernel starts to boot, the grub part is ok.
> >Normally, only the fs for '/' needs to be built in, but you seem to
> >have seen other issues so I would just build in everything you need.
> >
> >2.2 build in everything else you need to boot (normally, the disk
> >controller(s) ) so that you don't need an initrd.
> 
> That would be forcedeath, nouveau, v4l1 and 2 and hda_audio for starters.
> 

 Nouveau and forcedeath will probably be convenient, but the rest
ought to be ok as modules.  In this context, I mean whatever you need
for the kernel to get to a position where it can load modules.  So,
it needs the disk driver(s) and the root filesystem (where
/lib/modules lives).
> Since this kernel isn't near new enough for the config tricks mentioned, 
> maybe I'll see if the linux-stable I have can do a 3.11.0 checkout.
> 

> >2.4 for your convenience, ensure that you have enabled the config to
> >be stored in /proc/config.gz - once you are building your own
> >slimmed-down kernels, you probably won't want to mess about with
> >distro "install" scripts so just copying the bzimage to
> >/boot/vmlinuz-x.y.z, make modules_install, and editing
> >/boot/grub/grub.cfg (yes, really!) will save a lot of time.
> 
> My present script does everything but edit grub.cfg.
> 
[...]
> >3.  That might take two or three attempts to get to a good config,
> >but after that you should be able to use the slimmer config (from
> >zcat /proc/config.gz) to create .config for any newer version you
> >want to test or bisect, and then just run make oldconfig before you
> >build.
> >
> > Also, when you get back to bisecting, the version in the kernel
> >Makefile might not be what you expect.  If in doubt, you can change
> >it to something which doesn't overwrite any existing modules, e.g.
> >3.8.bisect-1 etc.
> 
> Presently it uses a + sign for in between versions.
> 
 I'm more familiar with bisecting in -rc versions : for those, the
Makefile version will jump back to what it was when the code was
developed.  Very confusing if you weren't expecting it.
> > HTH
> 
> It will, if I don't lose my place...
> >ؤ¸en
> 
> My "makeit" script does cd's here and there, so its vital that the Makefile 
> version matches the makeit version.  I've thought of that, and fixed it in 
> the copy I use to make a linux-stable install, but I haven't moved that 
> line of script into the tarball builds yet.
> 

 I haven't bothered to script my own kernel builds/installs for many
years - as you say, make sure everything matches.
> Having an automatic increment, I could eventually fill up the /boot 
> partition too. ;-)

 Been there (when /boot was small and used by several available test
systems).  For me, clearing out the old stuff by hand works well
en

Re: AMD microcode fails to update with v3.8.3 and newer, bisect failed

[Gene Heskett]

On Wednesday 01 January 2014, Ken Moffat wrote:
>On Thu, Jan 02, 2014 at 04:08:15AM +, Ken Moffat wrote:
>>  Anyway, best of luck and I hope you get it sorted.
>
> One further suggestion, since you appear to be at the "running
>round in circles" stage -
>
>1. Start with a good kernel.  In this case, I suppose 3.8.2 is the
>right place to begin.

That has since died, won't boot, don't recall changing a thing in the 
.config either.

>2. But then change the .config to -
>
>2.1 ensure that your disk filesystems are built in - e.g. all of
>ext2, ext3, ext4 and anything else you know you are using.

Should I edit in the /etc/grub.d to remove the modprobe ext2, or will it 
more or less silently shake its head and go on. 

>Normally, only the fs for '/' needs to be built in, but you seem to
>have seen other issues so I would just build in everything you need.
>
>2.2 build in everything else you need to boot (normally, the disk
>controller(s) ) so that you don't need an initrd.

That would be forcedeath, nouveau, v4l1 and 2 and hda_audio for starters.

Since this kernel isn't near new enough for the config tricks mentioned, 
maybe I'll see if the linux-stable I have can do a 3.11.0 checkout.

>
>2.3 drop the things you don't need - this is merely to reduce the
>time it takes to build a kernel.  Distros normally build
>_everything_ as a module.  Provided you can boot without an initrd,
>reducing the number of modules only makes it quicker to build a new
>kernel - but if you are starting from something which looks like
>"allmodconfig" it can save a lot of time.

I'll nominate that for understatement of the month. ;-)
>
>2.4 for your convenience, ensure that you have enabled the config to
>be stored in /proc/config.gz - once you are building your own
>slimmed-down kernels, you probably won't want to mess about with
>distro "install" scripts so just copying the bzimage to
>/boot/vmlinuz-x.y.z, make modules_install, and editing
>/boot/grub/grub.cfg (yes, really!) will save a lot of time.

My present script does everything but edit grub.cfg.

>2.5 Add your own version, e.g. for 3.8.2 change EXTRAVERSION to 2-A
>so that the kernel will be 3.8.2-A (this stops it overwriting
>existing existing 3.8.2 modules, in case the first attempt doesn't
>do what you want).

Never has yet anyway.

>3.  That might take two or three attempts to get to a good config,
>but after that you should be able to use the slimmer config (from
>zcat /proc/config.gz) to create .config for any newer version you
>want to test or bisect, and then just run make oldconfig before you
>build.
>
> Also, when you get back to bisecting, the version in the kernel
>Makefile might not be what you expect.  If in doubt, you can change
>it to something which doesn't overwrite any existing modules, e.g.
>3.8.bisect-1 etc.

Presently it uses a + sign for in between versions.

> HTH

It will, if I don't lose my place...
>ؤ¸en

My "makeit" script does cd's here and there, so its vital that the Makefile 
version matches the makeit version.  I've thought of that, and fixed it in 
the copy I use to make a linux-stable install, but I haven't moved that 
line of script into the tarball builds yet.

Having an automatic increment, I could eventually fill up the /boot 
partition too. ;-)

I take it that /proc/config.gz only keeps the lsmod output?  That would be 
sweet!  Great idea.

Thanks Ken & Cheers, Gene
--
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/

Re: AMD microcode fails to update with v3.8.3 and newer, bisect failed

[Gene Heskett]

On Wednesday 01 January 2014, Ken Moffat wrote:
>On Wed, Jan 01, 2014 at 09:25:55PM -0500, Gene Heskett wrote:
>> On Wednesday 01 January 2014, Jason Cooper wrote:
>> >Are the rootfs binaries 32 bit?  If so, did you enable
>> >CONFIG_IA32_EMULATION?
>> 
>> That line above does not now exist in my .config for 3.8.2. Ditto for
>> the .config in 3.12.6.
>> 
>> How is the best way to restore this?
>
> but Jason also wrote:
>> >You may be able to bypass your PAE problem by running a 64bit kernel
>> >with the above option.  Although, I'd prefer to get to the bottom of
>> >the failure. :)
>
>Gene -
>
> If I've understood you correctly, you are now running a 32-bit
>kernel - or perhaps 32-bit with PAE.  The CONFIG_IA32_EMULATION
>option is for a 64-bit [ x86_64 ] kernel, to enable it to run 32-bit
>userspace (either only 32bit userspace, or multilib).  So, it is
>irrelevant for a 32-bit kernel - those can only run 32-bit
>userspace.

That is one of the hills I am trying to climb.

> If your previous "good" kernel was either 32-bit or 32-bit with PAE,
>you might need to change a lot of .config settings to get a reliably
>working 64-bit kernel.  And vice-versa for a well-adapted 32-bit
>kernel if you had previously been running 64-bit.

All of my previous "good" kernels were 32 bit with or without PAE.  The 
important one is 2.6.32-122-rtai which is what it takes to run linxcnc, 
which I need to do for simulation runs occasionally.  That is what I am 
booted to ATM, but its a poor kernel for busy desktops, not PAE because 
that is a speed hit.  We are fixing that, but it hasn't dribbled down the 
hill to me yet, still "alpha" and these guys don't even want to ship Beta.

> Your main problem appears to be that part of kde is unusable, and
>you attribute this to the old firmware.  That may well be true (I
>don't use kde), but I will be very surprised if that is the
>_expected_ result of running the old firmware on an early phenom.
>Usually, running old firmware doesn't seem to make a lot of
>difference, except in obscure corner cases.  I will note that my own
>phenom *sometimes* seems to lose its lunch when running make -j4,

I've also found that, so my makefiles use -j3 and are ok AFAIK.

>and in those cases dropping the caches and running a
>less-adventurous parallel make [ -j3 or -j2 ] seems to fix it.  But
>that doesn't seem to be analagous to the kde problem you see (and
>when I last looked, a few months ago, my firmware appeared to be
>current, so I guess mine is the common "cheap consumer hardware" sort
>of problem).

Like me, you didn't buy the superdooper overclocked version. :)  This 9550 
is running at about 2.1Ghz and seems happy as a clam doing it.  I think 
you'd call it cheap consumer stuff.

> Anyway, best of luck and I hope you get it sorted.
>
> Perhaps I should also upset you by mentioning that 3.8 seems to be
>out of maintenance (except, probably, from ubuntu).  In general, the
>devs here aren't too interested in old kernels which are no longer
>supported.  OTOH, I'm reluctant to suggest what I would normally
>suggest in the "distro" (LFS) I care about - i.e. try both 3.12.0 and
>3.12.latest, both from a known good .config using 'make oldconfig' -
>because you are starting from an old version and it isn't obvious
>where the problem started.

I don't have any tarballs between 3.8.3 and 3.12.0 locally.  Perhaps a 
better starting point suggestion since I do know how to run gftp?

>Those of us with specific requirements
>really need to keep checking each kernel release (or ideally some of
>the later -rc versions) to make sure that things we care about
>haven't been trashed.

Yes Mike, I've been following your messages on this list for much of a 
decade.  Occasionally pretty pointed too. ;-)
>
>ؤ¸en


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

Re: AMD microcode fails to update with v3.8.3 and newer, bisect failed

[Ken Moffat]

On Thu, Jan 02, 2014 at 04:08:15AM +, Ken Moffat wrote:
> 
>  Anyway, best of luck and I hope you get it sorted.
> 
 One further suggestion, since you appear to be at the "running
round in circles" stage -

1. Start with a good kernel.  In this case, I suppose 3.8.2 is the
right place to begin.

2. But then change the .config to -

2.1 ensure that your disk filesystems are built in - e.g. all of
ext2, ext3, ext4 and anything else you know you are using.
Normally, only the fs for '/' needs to be built in, but you seem to
have seen other issues so I would just build in everything you need.

2.2 build in everything else you need to boot (normally, the disk
controller(s) ) so that you don't need an initrd.

2.3 drop the things you don't need - this is merely to reduce the
time it takes to build a kernel.  Distros normally build
_everything_ as a module.  Provided you can boot without an initrd,
reducing the number of modules only makes it quicker to build a new
kernel - but if you are starting from something which looks like
"allmodconfig" it can save a lot of time.

2.4 for your convenience, ensure that you have enabled the config to
be stored in /proc/config.gz - once you are building your own
slimmed-down kernels, you probably won't want to mess about with
distro "install" scripts so just copying the bzimage to
/boot/vmlinuz-x.y.z, make modules_install, and editing
/boot/grub/grub.cfg (yes, really!) will save a lot of time.

2.5 Add your own version, e.g. for 3.8.2 change EXTRAVERSION to 2-A
so that the kernel will be 3.8.2-A (this stops it overwriting
existing existing 3.8.2 modules, in case the first attempt doesn't
do what you want).

3.  That might take two or three attempts to get to a good config,
but after that you should be able to use the slimmer config (from
zcat /proc/config.gz) to create .config for any newer version you
want to test or bisect, and then just run make oldconfig before you
build.

 Also, when you get back to bisecting, the version in the kernel
Makefile might not be what you expect.  If in doubt, you can change
it to something which doesn't overwrite any existing modules, e.g.
3.8.bisect-1 etc.

 HTH

ĸen
-- 
das eine Mal als Tragödie, dieses Mal als Farce
--
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/

Re: AMD microcode fails to update with v3.8.3 and newer, bisect failed

[Ken Moffat]

On Wed, Jan 01, 2014 at 09:25:55PM -0500, Gene Heskett wrote:
> On Wednesday 01 January 2014, Jason Cooper wrote:
> >
> >Are the rootfs binaries 32 bit?  If so, did you enable
> >CONFIG_IA32_EMULATION?
> 
> That line above does not now exist in my .config for 3.8.2. Ditto for 
> the .config in 3.12.6.
> 
> How is the best way to restore this?
> 
 but Jason also wrote:

> >You may be able to bypass your PAE problem by running a 64bit kernel
> >with the above option.  Although, I'd prefer to get to the bottom of the
> >failure. :)
> >

Gene -

 If I've understood you correctly, you are now running a 32-bit
kernel - or perhaps 32-bit with PAE.  The CONFIG_IA32_EMULATION
option is for a 64-bit [ x86_64 ] kernel, to enable it to run 32-bit
userspace (either only 32bit userspace, or multilib).  So, it is
irrelevant for a 32-bit kernel - those can only run 32-bit
userspace.

 If your previous "good" kernel was either 32-bit or 32-bit with PAE,
you might need to change a lot of .config settings to get a reliably
working 64-bit kernel.  And vice-versa for a well-adapted 32-bit
kernel if you had previously been running 64-bit.

 Your main problem appears to be that part of kde is unusable, and
you attribute this to the old firmware.  That may well be true (I
don't use kde), but I will be very surprised if that is the
_expected_ result of running the old firmware on an early phenom.
Usually, running old firmware doesn't seem to make a lot of
difference, except in obscure corner cases.  I will note that my own
phenom *sometimes* seems to lose its lunch when running make -j4,
and in those cases dropping the caches and running a
less-adventurous parallel make [ -j3 or -j2 ] seems to fix it.  But
that doesn't seem to be analagous to the kde problem you see (and
when I last looked, a few months ago, my firmware appeared to be
current, so I guess mine is the common "cheap consumer hardware" sort
of problem).

 Anyway, best of luck and I hope you get it sorted.

 Perhaps I should also upset you by mentioning that 3.8 seems to be
out of maintenance (except, probably, from ubuntu).  In general, the
devs here aren't too interested in old kernels which are no longer
supported.  OTOH, I'm reluctant to suggest what I would normally
suggest in the "distro" (LFS) I care about - i.e. try both 3.12.0 and
3.12.latest, both from a known good .config using 'make oldconfig' -
because you are starting from an old version and it isn't obvious
where the problem started.  Those of us with specific requirements
really need to keep checking each kernel release (or ideally some of
the later -rc versions) to make sure that things we care about
haven't been trashed.

ĸen
-- 
das eine Mal als Tragödie, dieses Mal als Farce
--
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/

Re: AMD microcode fails to update with v3.8.3 and newer, bisect failed

[Gene Heskett]

On Wednesday 01 January 2014, Randy Dunlap wrote:
>On 01/01/14 18:40, Gene Heskett wrote:
>> On Wednesday 01 January 2014, Gene Heskett wrote:
>>> On Wednesday 01 January 2014, Jason Cooper wrote:
>> Can you please repost that X64 default configuration "make" line, that
>> message seems to have encountered my expiry rules.
>> 
>> Thanks Jason.
>
>Jason said:
>$ make x86_64_defconfig
>[in http://marc.info/?l=linux-kernel&m=138829693820368&w=2 ]
>
>
>I would have said:
>$ make ARCH=x86_64 defconfig

Didn't take but 2 or 3 seconds for your version, thanks Randy.

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 try to teach a pig to sing.  It wastes your time and annoys the pig.
-- Lazarus Long, "Time Enough for Love"
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 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/

Re: AMD microcode fails to update with v3.8.3 and newer, bisect failed

[Randy Dunlap]

On 01/01/14 18:40, Gene Heskett wrote:
> On Wednesday 01 January 2014, Gene Heskett wrote:
>> On Wednesday 01 January 2014, Jason Cooper wrote:
> 
> Can you please repost that X64 default configuration "make" line, that 
> message seems to have encountered my expiry rules.
> 
> Thanks Jason.

Jason said:
$ make x86_64_defconfig
[in http://marc.info/?l=linux-kernel&m=138829693820368&w=2 ]


I would have said:
$ make ARCH=x86_64 defconfig


-- 
~Randy
--
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/

Re: AMD microcode fails to update with v3.8.3 and newer, bisect failed

[Gene Heskett]

On Wednesday 01 January 2014, Gene Heskett wrote:
>On Wednesday 01 January 2014, Jason Cooper wrote:

Can you please repost that X64 default configuration "make" line, that 
message seems to have encountered my expiry rules.

Thanks Jason.

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

Re: AMD microcode fails to update with v3.8.3 and newer, bisect failed

[Gene Heskett]

On Wednesday 01 January 2014, Jason Cooper wrote:
>Gene,
>
>Most people on this list receive several _hundred_ to a couple thousand
>emails per day.  Please use a concise and descriptive Subject line so
>your email catches the eye of folks who can most help you.  I've updated
>it in this reply to:
>
>Subject: AMD microcode fails to update with v3.8.3 and newer, bisect
>failed
>
>An interesting point, when bisecting from v3.8.2 -> v3.8.3, all tested
>kernels work *except* v3.8.3.  When bisecting the other direction, from
>v3.8.3 -> v3.8.2, all kernels fail *except* v3.8.2.  This leads me to
>believe it is a configuration problem.
>
>Gene, could you build v3.8.2, confirm it works, and send the config
>file?  Then do the same for v3.8.3 (confirm fail, though) and send that
>config as well?

I tried that after sending this message.  The 3.8.2 from a tarball, and 
which I had been getting known good .configs from, reinstalled, now fails, 
can't mount /boot or some such. And I now have it mounting and dismounting 
via a LABEL="ububoot" in my /etc/fstab.  UUID's must have gone to hell when
I disabled the floppy in the bios.

Currently on 3.12.6, a tarball based build, PAE without the microcode 
patching according to a "dmesg|grep microcode" output

gene@coyote:~/src/linux-3.12.6$ sudo umount /boot
[sudo] password for gene:
gene@coyote:~/src/linux-3.12.6$ df
Filesystem   1K-blocks  Used Available Use% Mounted on
/dev/sda2955387652 255678680 651154988  29% /
none   4146908   436   4146472   1% /dev
none   4153304  3716   4149588   1% /dev/shm
none   4153304   260   4153044   1% /var/run
none   4153304 4   4153300   1% /var/lock
none   4153304 0   4153304   0% /lib/init/rw
/dev/sdc2960929128 513222732 398893956  57% /amandatapes
/dev/sdb1953178004  69667928 835091364   8% /media/ubu12.4.2
/dev/sdd1482336436 198274624 259537472  44% /media/home2
lathe:/home/gene 234470400   4697856 217862144   3% /net/lathe/home/gene
shop:/home/gene  234470400   7113728 215446016   4% /net/shop/home/gene

not there.

gene@coyote:~/src/linux-3.12.6$ sudo mount LABEL=ububoot /boot
gene@coyote:~/src/linux-3.12.6$ df
Filesystem   1K-blocks  Used Available Use% Mounted on
/dev/sda2955387652 255678688 651154980  29% /
none   4146908   436   4146472   1% /dev
none   4153304  3716   4149588   1% /dev/shm
none   4153304   260   4153044   1% /var/run
none   4153304 4   4153300   1% /var/lock
none   4153304 0   4153304   0% /lib/init/rw
/dev/sdc2960929128 513222732 398893956  57% /amandatapes
/dev/sdb1953178004  69667928 835091364   8% /media/ubu12.4.2
/dev/sdd1482336436 198274624 259537472  44% /media/home2
lathe:/home/gene 234470400   4697856 217862144   3% /net/lathe/home/gene
shop:/home/gene  234470400   7113728 215446016   4% /net/shop/home/gene
/dev/sda1  1007896333288623408  35% /boot

looks good.

So there is no problem I can see.  But 3.8.2 is now failing.

So, how far forward can I take a bisect, starting at v3.8.0 using the 
linux-stable clone pull?  I started to yesterday, but ran into the non 
mount of /boot problem which ate my lunch and I did not reset it yet.

>On Wed, Jan 01, 2014 at 05:51:59PM -0500, Gene Heskett wrote:
>> Greetings;
>> 
>> Back on the failure of the amd microcode to properly update the cpu. 
>> It seems to be somewhat interlocked with PAE.
>> 
>> Basically, 1. a 64 bit kernel will not boot, I think because it cannot
>> access the /boot partition to find its corresponding initrd file.
>
>Are the rootfs binaries 32 bit?  If so, did you enable
>CONFIG_IA32_EMULATION?

That line above does not now exist in my .config for 3.8.2. Ditto for 
the .config in 3.12.6.

How is the best way to restore this?


>You may be able to bypass your PAE problem by running a 64bit kernel
>with the above option.  Although, I'd prefer to get to the bottom of the
>failure. :)
>
>>  And if I check it, the rest of my .config is mix-mastered, and I have
>>  to copy a known good .config back into that tree before I can make a
>>  PAE kernel that actually boots.
>> 
>> 2. If I build w/o the PAE, then the microcode update works most of the
>> time.
>> 
>> 3. With PAE, it hasn't worked since 3.8.2 final.
>
>In addition to the two configs I mentioned above, could you do them with
>and without PAE (so four total)?
>
>> 4. I am building several thousand modules I don't need, because while I
>> can turn them off, about 2500-3000 of them but they are found to be
>> back on after a build and an attempted boot to that build fails, or
>> doesn't mount the /boot partition.  Its a failure either way.
>
>What is the exact series of commands causing this?  Are you saving your
>configs and