apparent loss of continuity in kernel .config?

apparent loss of continuity in kernel .config?

[Gene Heskett]

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.

Cheers, Gene Heskett
-- 
"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

Re: apparent loss of continuity in kernel .config?

[rh_]

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.

Re: apparent loss of continuity in kernel .config?

[Gene Heskett]

On Thursday 01 January 2015, rh_ wrote:
>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.

IMO that is NOT how its supposed to work.  So I guess I'll waste a tree 
and print a working  3.16.0 & use that to build a new one. I do not 
believe it even makes an attempt to read the old one, but simply goes 
wandering in the vineyard, making frequent stops to recycle the barrel 
sampling.

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

Indeed, but it no doubt will take quite a few boxes.  The funny thing lots 
of people find hard to believe is that Ed wrote that in about 1940.  His 
long view obviously started before mine as mine didn't start will late in 
'34.  It took me till the middle 60's to decide its broken.  And every 
libtard fix breaks it worse...


Thanks & lets hope 2015 is a better year.

Cheers, Gene Heskett
-- 
"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

Re: apparent loss of continuity in kernel .config?

[rh_]

On Thu, 1 Jan 2015 18:43:03 -0500
Gene Heskett <gheskett@wdtv.com> wrote:

> 
> IMO that is NOT how its supposed to work.  So I guess I'll waste a

I agree.

> tree and print a working  3.16.0 & use that to build a new one. I do
> not believe it even makes an attempt to read the old one, but simply
> goes wandering in the vineyard, making frequent stops to recycle the
> barrel sampling.

I used to try to make it work but I usually give up and stick with
the config that works. Maybe I'm doing it all wrong. My laptop works
fine though. But it wasn't easy building a static kernel for it.

> 
> Indeed, but it no doubt will take quite a few boxes.  The funny thing

Probably true.

> lots of people find hard to believe is that Ed wrote that in about
> 1940.  His long view obviously started before mine as mine didn't
> start will late in '34.  It took me till the middle 60's to decide
> its broken.  And every libtard fix breaks it worse...

Smedley Butler and lots of others knew a long time ago too.
G.E. Griffin and friends have lots to say.

The long-con is always hard to see.

> 
> 
> Thanks & lets hope 2015 is a better year.

Can do.

> 
> Cheers, Gene Heskett
> -- 
> "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

Re: apparent loss of continuity in kernel .config?

[Geert Uytterhoeven]

Hi Gene,

On Wed, Dec 31, 2014 at 3:16 PM, Gene Heskett <gheskett@wdtv.com> wrote:
> 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.

Being someone who runs "make oldconfig" and compares .config.old and .config
all the time, I never saw this. However, those are almost never x86 oldconfigs.

Did it change from 64BIT=y to no or vice versa?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds