From: rh_ <richard_hubbe11@lavabit.com>
To: linux-kernel@vger.kernel.org
Subject: Re: apparent loss of continuity in kernel .config?
Date: Thu, 1 Jan 2015 11:24:24 -0800 [thread overview]
Message-ID: <20150101112424.2accee4e@127> (raw)
In-Reply-To: 201412310916.57808.gheskett@wdtv.com
On Wed, 31 Dec 2014 09:16:57 -0500
Gene Heskett <gheskett@wdtv.com> wrote:
> Greetings;
>
> Usually, when I build a new kernel, just placing a copy of an older
> versions .config in the unpacked src directory is sufficient that
> only what has been changed has to be answered during a make
> oldconfig, perhaps a couple dozen new features need to be answered
> yes or no, and I have a .config that will usually build me a bootable
> kernel. Not any more.
>
> Since my 3.16.0 has been suffering from stalls of up to 2 or 3
> minutes while both htop and gkrellm continue to report that there is
> nothing hogging the machine, in a general description that matches
> the Dave Jone saga, but w/o the log spew, probably because I don't
> have extreme debugging enabled.
>
> But its strange in how it manifests itself as it will do it from a
> fresh boot, and I get aggravated and reboot, and it doesn't do it
> till the next reboot which may be a month later. Almost an alternate
> boot phenomenon.
> Attempting to go from 3.16.0 to 3.16.7 last night, a make oldconfig
> started from scratch as if there were no .config's in the directory.
> I stood on the enter key to take the defaults, then ran a make
> xconfig to discover it was totally wrong for an AMD phenom, no
> networking, no disc drivers, video was an old ATI, when there is an
> nvidia card in it, yadda, yadda.
>
> I went thru this exercise 4 times, as I keep a gzipped copy on the
> config that built the kernel version in the boot directory with my
> build script. And every time it was the same story.
>
> Obviously I can't, at 80 yo, remember every item in a 28k .config
> file from build to build, so what am I doing wrong that is destroying
> this continuity?
>
> Thanks everybody.
Have you had any replies? I do similar but I may be less patient
than you. I keep dragging around my previous .config and when it
no longer works I just stay with the kernel that's working. And try
again later. It's been interesting to see what new things default
to "yes" along the way.
I would not call it "loss of continuity", I would call it loss of
backward compatibility. If the kernel breaks userspace it causes
a shitstorm but if the kernel breaks the kernel buildspace you're
supposed to suck it up and make a new .config from scratch.
> "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>
> US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
Since voting machines,SCOTUS and juries have been compromised it
seems we're down to that last box.
next prev parent reply other threads:[~2015-01-01 19:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-31 14:16 apparent loss of continuity in kernel .config? Gene Heskett
2015-01-01 19:24 ` rh_ [this message]
2015-01-01 23:43 ` Gene Heskett
2015-01-02 16:59 ` rh_
2015-01-02 9:31 ` Geert Uytterhoeven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150101112424.2accee4e@127 \
--to=richard_hubbe11@lavabit.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.