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]

Message-ID: <20140102040815.GA25619@milliways>
Date:	Thu, 2 Jan 2014 04:08:15 +0000
From:	Ken Moffat <zarniwhoop@...world.com>
To:	Gene Heskett <gheskett@...v.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 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 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/