Message-Id: <201401021812.05431.gheskett@wdtv.com>
Date:	Thu, 2 Jan 2014 18:12:05 -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 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 +0000, 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
>enough.  For scripts, I guess that you already check $?.
>
>> I take it that /proc/config.gz only keeps the lsmod output?  That would
>> be sweet!  Great idea.
>
> No, it has everything from .config - but gzipped.  Provided the
>kernel boots, it will tell you how it was configured.  If it doesn't
>boot, the problematic config is in the source tree.  Also saves
>space in wherever a distro stores the config.
>
>> Thanks Ken & Cheers, Gene
>
>ؤ¸en

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

Old men are fond of giving good advice to console themselves for their
inability to set a bad example.
		-- La Rochefoucauld, "Maxims"
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 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/

Powered by blists - more mailing lists