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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 1 Jan 2014 23:53:14 -0500
From:	Gene Heskett <gheskett@...v.com>
To:	Ken Moffat <zarniwhoop@...world.com>
Cc:	Jason Cooper <jason@...edaemon.net>, linux-kernel@...r.kernel.org
Subject: Re: AMD microcode fails to update with v3.8.3 and newer, bisect failed

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/